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While cost containment is certainly the most publicly visible concern in medi- 
cal care today, hospitals are under just as much pressure to improve the qual- 
ity of patient care. Since they can invest in new equipment only every seven to 
^^^^ J fifteen years, hospitals want that equipmentto be easy to upgrade and adapt 
' ' T i ^3B^^ to new technologies, In designing HP's fourth-generation patient monitoring 
system, the engineers at HP's Medical Products Group had to deal with these 
and other issues influencing their hospital customers' investment decisions. 
^ The design of the new system, which they call the Component Monitoring 

System, emphasizes modularitYn flexibility, and ease of use while addressing 
the increasing need to measure new patient parameters and to process this 
information using powerful algorittims and data management tools. The article on page 6 introduces the 
system and its overall architecture, while details otthe hardware and software architectures can be 
found in the articles on pages 10, T3, and 19. The necessary functions of data acquisition, parameter 
signal processing, display, and system connections are implemented as hardware and software building 
blocks. Application software modules, such as the blood pressure measurement software, can be arbi- 
trarily assigned to any CPU in a loosely coupled multiprocessor system. The applications think that they 
are running on a nonexistent virtual processor. The architecture makes it easy to configure the system 
for both current and future needs in the operating room, intensive and cardiac care units, and other hos- 
pital areas, and contributes to a greatly simplified, low-cost production and test process, Patient param- 
eters such as blood pressure, the electrocardiogram (ECG), blood gases, temperature, and others are 
measured hy state-of-the-art modules that can be located close to the patient while the signal processor 
and displays can be in another room, if necessary. The ECG, blood pressure, and recorder modules are 
described in the articles on pages 21, 25, and 26. The system not only provides the clinician with the raw 
data measured by these modules, but also processes it, as explained in the article on page 40, to obtain 
many meaningful indicators of physiological functions, such as ventricular ejection and systemic vascu- 
lar resistance. Ease of use is delivered by a thoroughly tested user interface design (see page 29), which 
can be localized easily for most languages (page 37). Mechanical design, software testing, and produc- 
tion and fina I test of the Com ponent Mon ito rin g System a re the s u bjects of the articles on pages 44, 49, 
and 52. 

The personal computer, or just PC, based on the Industry Standard Architecture (ISA) pioneered by the 
IBM PC, has gained steadily in processing power as each new generation of Intel microprocessors was 
introduced. The HP Vectra 486 PC uses not only the latest-generation microprocessor, the tntel486, but 
also the new Extended Industry Standard Architecture (EISA). The lntel4B6 integrates the CPU, a cache 
memory, and a math coprocessor onto one chip running at 25 or 33 megahertz. The EISA takes the 16-bit 
ISA bus to 32 bits while maintaining compatibility with all ISA I/O cards. The design otthe HP Vectra 4S6 
shows that designers can still contribute creatively within the constraints of industry standards. Among 
the design contributions are an architecture that incorporates all of the new technical features of the 
EISA and adapts easily to faster versions of the Intel486, a bus connector that accommodates both EISA 
and ISA cards, a burst-mode memory controller, a high-performance hard disk subsystem, and enhance- 
ments to the Vectra s basic I/O system (BIOS) to take advantage of all of the new features. An overview 
of the Vectra 4S6 design appears on page 69, and the articles on pages 73, 78, and S3 discuss the con- 
nector, memory controller, and BIOS designs. Performance analysis of many of the design concepts was 
done using a specialized hardware and software toolset, allowing the designers to make critical design 
trade-offs before committing to hardware (see page 92(, 
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How mych does a software detect cost in terms of ynnecessary expense and iost profit? Why is ft impor- 
tant to know? As Jack Werd of HP's WaWiam Division explains in the article on page 55, if yotiVe trying to 
jtisiifv the cost of a new software development tool <t helps to know what the tool will save by reducing 
software defects. He proposes an algorithm for computing the cost of software defects, applies it to a 
fjve-year database of software product releases, and shows that defect prevention and early removal 
can save a lot of money. 

Code inspections are now standard procedure in many software development organizations. Are they 
effective? The article on page 58 describes the results of one HP division's effort to collect data to hnd 
out. There are both positive and negative findings, but the conclusion is that formal inspections are 
beneficial, while the value of informal inspections is still open to question, 

R.P Dolan 
Editor 



What's Ahead 

The December issue will feature HP Sockets, a software too! for integrating applications in a network 
environment. An article from HP Laboratories in Bristol, England will introduce HP's formal specification 
language, HP-SU and four articles will present examples of the use of HP-SL in software development 
Another article will describe the HP Network Monitoring System for telecommunications networks using 
the 2-Mbit/s primary rate interface and the CCITT RZ or #7 signaling system. The 1D91 index will also tje 
included. 
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Introduction to the HP Component 
Monitoring System 

This fourth-generation patient monitoring system offers a set of hardware 
and software building blocks from which functional modules are 
assembled to tailor the system to the application and the patient. 

by Christoph Westerteicker 



CKcr the past twenly years IIP htis been a supplier of 
patient monitoring equipment to I he lieaJthcare iiidustiy 
Pationt monitors arc observational and diagnostic tools 
that monitor physiological paianietei"s of critiealiy ill pa- 
tients. Typie^il parameters iJiclude the elect roeardiogiam 
(ECG), blood tiressure meastn'ed botli invasiveiy and non- 
invasively, pulse oximeter (SaO;^), and respiratory- gases, 
among ot!iers. The catalog of parameters is still growing 
based on tlie need ffjr !)etter patient care and the lechni- 
caJ feasibility of new measuremenl techniques. 

Patient monitors are used in a variety of depail.ments 
within hos})itals. Tliese include operating rooms, intensive 
care units, ear(iiac care units, in -hospital and on t -of- hospi- 
tal Iransportatiou, and st>t'<^'J3^J funciion areas such as 
lithotripsy and x-ray. A patient monitoring system mnsl be 
versatile and apphcable to mosi: of these areas. This 
means that it must support a wide range of configurations 
and allow quick adaptation to the patient-s])ecific level of 
care. For a nomial apt>endectomy, mc)nitoring die Ef'(i, 
noninvasive blood jDic^ssure, SaO^. and one temperature 
will Hiiffiee. At the otlier extreme, during a caidiovasculai' 
operation as many as eight different physiologicai paranie- 
ters will be measured. 

The IIP Component Monitoring System is designed to 
meet these requirements. This article outlines the liigli-lev- 
el project goals and the api)roaches laken lo nux't ihem, 
it £ilso describes the overall Itardware ajid softvy-aie arclii- 
tecttire of the HP Component Monitoring System- Subse- 
quent articles in ihis Issue higldighl the lechniciil contri- 
liutitms of the Component Mcjnituiing System t>roject in 
more detail- 
Design Goals 

The MP Comi)onent Monhoring System is the ftjurth gen- 
erati(m of patient momioi-s ro be dc^signed ajitl Iniilt by 
tlie HP Medical Products Group. Based on otir exix^ri- 
ence. cunent customer needs^ and expected fvUure trends 
in the medical field, two ol)jecii%'es were \^e^^'ed as ateas 
in which HP could make a nu^jor contribution. One is the 
aiea of modularity ajid flexibility and the other is ease of 
use. 

Modularity and Flexibility. The monitor is composed of the 
following functional modules: 
Data acquisition 
Parameter signal processing 



• Monitor control and data hiput 

• Display 

• System connecis, 

Kach of these functional modules is implemented in a set 
of hardware and software buihiing blocks, which as a 
wiiole form I lie (^^^^►onent Monitoring System depicted 
in Fig- L Separating the monitor into its generic elements 
provides many advantages. Fir-sl. the monitor can easily 
be configured to best meet the application needs of the 
individual customer Parameters can quickly be combine*! 
according to the ret^uired level of care ajul changed when 
necessary. Second, adding functionality to a monitor is as 
sbnple as inserting the appropriate bajxlwaie into an ex- 
isting unit and u]:»fiaiing the softw^are if necessaiy^ 

A tliird at! vantage is that the Component Monitoring Sys- 
tem can be kept abreasi of new tecbrinlogical trends by 
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Fig. X. In the- HP Clomponejit MoniT tiling Syi^tc?iii. a ruiirth-geiiem- 
iitjw patit^nl rnanilJjf, envh fuiictiDrm] nmclulp is inipiemented in a 
sfpt of hardware and seftware bniJding blocks. 
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Fig, 2, Tlio Cf>rTif>iini^nt MnriitDnn^ Svfvti-ni arrhitcc^niro has iJiroc 
segnietits: the nittdiile rdvk and p^iraitieier riKHliiles, tlu- ifimpulf^r 
niiMlule, and the dispki>s, The modulo rack can be ^}\hvT iin integral 
part i>f Ihp romputer modiil<^ or tniaJly dorai hc-d. A reniole keypad 
H Dptlojml 

enhancmg or redesigning the appropriate functioiial ole- 
mepl. Iniplcnioriiatinn \dli only iiffect one building biock, 
ajKl will be fully barkwiiixl cornpaiible with existing sys- 
lenis. 

Finally, iirodurtion has bepn dramatieally simplified. Cus- 
lomization of each monitor is the last iuregrati(jn step in 
produelion. Thus, all components cm\ \w assembled and 
lesteti wilhont knowing tiie spefitlc ronfignration in 
whi( ii liiey will be usfiL 

Flexibility is enhanced by designing the ntonitor compo 
nents so that their physical location vnn l)e oplimized to 
address ergoncjinif c^onsiderations and l>y allowing the 
user to program the nioniior's default si*ilings and stan- 
daix! coiirtgnratirHL This means thai the monitor can lu^ 
adapted lo a wide ran^e of rtment and biuae elinical 
applications. 

Ease of Use. Ease of nse is of particular importance for 
patient nuaiitors in operating rooms arul t litiral care 
units, where chnirians use patient monilors to make in- 
fomied decisions ab(3Ut t>oteudally Ufe4hreatening situa- 
tions. In the past, clinicians have had to strike a compro- 
mise between the desiroil fimclionaiity of a patient 
monitor mtd its ease of use. tJur goal wiis to mak(^ this 
ver>^ sophisticated piece of equipment tnily irtluitive for 
doctors anrl nurses to use. Otht^r areas that w(^ focused 
on, iuid thai [ilayed an important role timing the develojj- 
ment phase were: 

• Implementation ofmethodsto mt^t tlPt|nalily goals. 

• Minimizalion of product ion costs and suptam for a linear 
cost prolllt*. This means thai funciionality can be seg- 
inente<l tiowii ttj its |j;eneric building blocks. Should a par- 
ticular fealiue be needed, the customer pays for it tuid 
nothtn^ more. 

• St and at i ligation, ranging from milform design tools and 
software development enviromuents all tin* way in mini- 
mizing the number of diffennit eleclrical component.*^ 
a.sed in the (!om|K)neut Monitoring System as well as the 
nuiuher uf luechaiiical parts needed to assemble the unit. 



System Arehitecture 

From an arctdiectural standpoint Hie Componeni Monitor- 
ing System can be divided into thrf?e segments (see F^g. 
2): 

• Module rack Hitli parameter modules 

• Computer module 

• Displays. 

The module rack and parameter modules represent the 
interfaf^e to the patient. Each parameter module Is dedi- 

<'ated to the measurement of one or morm^ physiological 
signals, and is housed in a separate enckisure. Within the 
parameter modules, the transducer signals are electrically 
Isolated from ground potential, amplifietl, sampled, and 
converted from an analog to a digital format. The digital 
parameter values together with the status of each module 
are polled at Hxed intenals aitd sent to the computer 
module for further interpreiairon- 

Up to eight single-width modules fit into one mofhile 
rack- The module rack ciUi be either an integial part of 
the computer module or toiaily detached, in wiiich c£^e It 
would be called a saleilite module rack. The satellite 
module rack Is connected to the coniiiuter module by mi 
uinbilical-cord-like cable, which c^arries tioth the digital 
signals mu\ a 60V dc [iovver luie for the paiameter mod- 
ules. One computer uuKiule can support as many as four 
satellite aiodule racks. This concept allows the user to 
position the parameter modules as ch>se as possible to 
the patient, where the signal is measured. The transducer 
cables can thus be ke|>l short, ntiiiimizing the amonrtt of 
\\ iting as wi^l as the tendency for it to become tangled 
or draped over the patient, 

Coniputer Module 

Tlu^ compuler auKiule is llie main processing unit. It con- 
sists of a cardcage thai can liousc^ up to 2-i fiuution 
cards and one dc-to-dc converter (Fig. 3). Fimeiion Ciirds 
currently available^ include t'PlIs, memorj' cards, interface 
cards, display cfjnt rollers, aiul a utihty card. For the first 
release, a total of 11 fund ion carets wen^ designed. Tlte 
inteicHjnnection within the c;mlcage takes placi^ via the 
central plane, a mcstherboard lo<*at.ed in the middle of tlie 
chassis with press-fit connectors mounted on l>oth sides 




^•-'"^1$:«% 
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Fig, 3. TIh^ nmipntcr nutduEf^ hoiiKes np ii- 'S'^ mrnnim rrarcts. 
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Ugieal Dala Buses 




Fifst-Levfil 
ProcessJFig 

Signal 
Acq uES4 lion 



Fig, 4> Functional block diagrdni of a Cdmponent Monitoring Sys- 
tem patient nionilor. The stiaded boxes are software fuiictioiis on 
tlie CPU card processors, The solid bo^es are specific Jiardware aiicJ 
firmware fiincUqns. 



of a printed circuit board. Data exchange between the 
function cards lakes pJace on the mcssaj^e piissing bus. 
Ttiis bus is routed to all 23 slots on the central plane, 
allowing a high degree of freedom as to where a function 
card can be inserted. The message passing bus is the 
backbone oJ' the Component Monitoring SystcnL Many of 
the goals listed above only became possible with the help 
of ti^is conmuinication concept. 

The basic function of the message passing bus is that of 
a broadcast system. Each message sent on the bus con- 
sists of a header, which describes the content, and the 
actual data. A source (e.g.. a CPU card) will obtain con- 
trol of the message pa^ssing bus and transmit its informa- 
tion. Tbe data is not transmitted in a point-to-point fash- 
ion from one source to one receh/er. Instead, message 
passiT\g bus data Is transmitted with out iiny specific desti- 
nation, imd ii is up to the function cards to watch for tiie 
info nn at ion needed by their apjilications. x\s soori as a 
card detects a match between a header it is looking for 
and the header of the message on the bus, it antoniatieaU 
ly pulJs this data into an internal stack. 

The aeti\1ties of bus arbitration, transn>Jssion, header 
matching, aiKl data reception are controlled by the mes- 
sage passing bus chip. One of these interface chips is 
located on each ftmction card that actively takes part in 
the communication process. The chip was designed spe- 
cifically for tbe Component Monitoring System, li also 
was the first HP production ASIC (application-specific IC) 
to be designed using a silicon compiler tooL 

A more detailed description of the message passing bus 
concept and the design of tjie interface chip can he found 
in the article on page 10, which covers the Component 
Monitoring System hardware architecture. 



Displays 

The customer can choose either a monochrome or color 
high-resolution display Multiple independent displays can 
be used to present different sets of information to specif- 
ic user groups. For exantple, tlio surgeon needs a differ- 
ent presentation of patient information than the anesthe- 
siologL^t during surgery. 

Physically separating the display from the computer mod- 
ule gives the user a choice of screen sizes and the possi- 
bibty of mounting the computer module at a remote loca- 
tion when space next to the patient is at a premium. 

The user interacts with tJie monitor through a combina- 
tion of hardkeys and soft keys on the display keypad or 
through a remote key^^ad which functionally duplicates 
the keys on the display bezel. 

Software Modularity 

The concept of a modular system also apphes to the soft- 
ware architecture (see Fig. 4). AppUcati on-specific mod- 
ules represent the basic building blocks out of which the 
total solution can be assembled. The ECG application, for 
example, including the signal interpretation, alarm han- 
dlhig, and control interaction, is all encapsulated in one 
module. To the surrounding cn\ironment these application 
software modules aie totally self-contained packages, and 
only exchange information with one another via the mes- 
sage passing bus. By virtue of tliis concept, it is possible 
to link each module as an independent entity with ^my of 
the other ukkIuIcs and assign it to one of the Component 
Monitoring System CPU cards. 

A more detailed description of the software architecture 
can be found in the aiticle on page 13. 

AH of the Component Monitoring System software is 
stored on EPROM function cards. These cards are physi- 
cally located next to a CPU, and the appUcations mnning 
on that CPU execute directly from the atljacent memory 
card. All other CPU cards in the monitor gel their appU- 
cation software dovi^iiloaded into tlte on-board RAM dur- 
ing boot time. Tbe advantage of this solution is that in- 
stalling software is as easy as inserting one EPROM card. 

Summary 

The Component Monitoring System has proved that the 
concept of component modularity can be extended far 
beyond tlie mere ability to mix and match parameter 
modules. Modularity iji this systetu means that the cus- 
tomer can tailor the patient monitor to best fit the appli- 
cation all the way fi:om the paiameters that need to be 
registered to the displays and interfaces the systetti 
should incorporate. The Component Monitoring System 
can also grow with the user's needs over time, and thus 
sectire the hospitals assets for many years. 

The success of the modularity concept is reflected in the 
fact that some of the hardware and software elements 
have found their way into other medical devices manufac- 
tured by HP Overall, the Component Monitoring System 
architecture has proven it can function as a monitoring 
platfonii for years to come. 



f 
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Medical Expectations of Today's Patient Monitors 



HP has been a supplier of patient nsjnitDfS since ifie mid- 1 960s. Ttw HP 7^0, HP , 
7a2xx. HP 7KSx. and HP 7BS3>: mmitors have measured wjtsi signs Nke KG. blood 
prKsore, body temperatufe. carbon dioxide. insfHred OKvsen, and others 

Ovef ttie v^TS. ctistomer demands and measiuremem techmlogy have both devet- 
(jpe[t rrecorne compJex fnontionng solutrons. 

acqii! g many parameLefs. These modern 

monitofs neaj lo cammtinicate ovet defltc^ied LANs, both with or« anotfer and 
with {^tral stations Fof this purpcjse. severat yeare ago, HP introduced a senal 
djstnbution network (SOf^^, wtiich makes it possible lo tfansmit a multitude of 
parameters, htgh-fesolutton waveforms, and other mformatio^ lo as many as 32 
pnicj pants m a synchronous way These features are not east ly achievable with 
modefn asynchronous lAMs, 

Medical Expectatiorts 

Most ot today s patient monitors do not satisfactorily fulfill rnany of the current 

and future expectations for Ihese systems. The increasing need to measure new 
parameters and to pasiprocess this information usmg powerful signal processing 
algorithms and data management tools require a different approach At the seme 
time, our customers are under tremendous cost containment pressure, allowing 
them to invest m new equipment only in cycles of seven to fifteen years Having 
these and other customer needs in mind, we launched a development program for 
a new patient monitoring system. The goals of our project were to: 
Develop a solution that can be easily adapted to our worldwide cystomers' medi- 
cal as well as financial needs 

Develop a user interface that allows the user to control the system easily through 
different means including softkeys. touch, and remote keyboards (see article, page 

Develop a solution for all major languages, including Asian languages. 

Develop a solution that is backwards compatible with the e5(isting LAN (SDf^l and 

future LAN implemontatrons. 

Develop a solution corresponding to our customers' space restrictions. This often 

means acquiring measurement data close to the paiient to avoid the so-called 

"spaghetti syndrome"— too many cables around the patient — and processing 

and displaying the measurement data farther away from the patient. 



DeveiE^ a soluuoo that allows addiuoral CPUs to be atkJed to the syssm acciffri- 
ing to the signal pfQc^sir?g needs, and that provides rndeperxteit displays that 
can be addressed directly 

Conclusion 

The HP Compon^t Monitonng System is ouf solution to these rweds Fig I shows 
tfffi bedside monitOfing conc^t of this systerr Expansion is possible hoih hori^n- 
tally and vertTcally in this matri)? The hariiDnial axis shows the various fufictronal 
needs, while the vertical axis shows various ways in whfch these needs are met m 
specffic applications. The last row of the matrix shows ejcamples of possible future 
capabilities that cen be added easily to the Component MonitDfing System if and 
when they become available- 

The HP Component Monitoring System is an ultratlexible patient monitoring sys- 
tem that can be adapted to almost all monitoring needs that arise in hosprtals 
worldwide. Its built-in modularity and an HP proprietary message passing bus 
make it independent of technology changes m microprocessors. LANs, or displays. 

This IS expected to result in a very long product lifetime., thereby protecting our 
customers' investments. By offenng different configurations of the Component 
Monitonng System, we provide a wide pr ice/performance range, and through a 
flexible upgrade strategy, we ensure high adaptability to our customers' future 

needs 

The Component Monitoring System is a truly iniernational development ihat in- 
volved engmeers in the U.S A and in Europe. Today, it is being manufactured at 
two HP sites, one in Europe and one in the US. A. 

Such a significant technology step can never he taken without encountering chal- 
lenges. Thanks to the engagement and dedication of all of the team members, 
these challenges were met successfully 

Frank Rochlilier 

Genera! Manager 

Surgical and Neonatal Care Business Unit 
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Ac knowled gme n ts 

Tlie clesign of the t*omponent Moniloring System has 
been a team effort invoKing at tiriies up to 50 pngineei's 
located at the Walt ham and Bohhngen Medical Div^isions, 
All of these individuals and many others deser\T' recogni- 
tion for their hard work lo make this t>rodtict a success. 
I would also like to thank all who conliibuied to this 



series of articles on the Component Monitoring System- 
Besides the authors of each chapter, and the numerotis 
unnanted supporters, one person deserves particular rec- 
ognition: Heike Schreiher. Her contmiied entlmsiasni eind 
devotion helped lo make this issue of the UP Jounial 
possible. 



Component Monitoring System 
Hardware Architecture 



Up to 23 function cards residing in a computer module communicate over a 
message passing bus. The computer module, the display, and the 
parameter modules that measure vita! signs can be in separate locations 
as needed by the application. 

by Christopli Westerteicher and Werner E. Heim 



The prime ohjertive in the development of the UP Cqju- 
j>onent Monitoring System was to build a patient monitor 
that would adapt optimally to the [najority of clinical 
applications, now and in the foreseeable futur'e. To tlie 
R&D team, this meant modularity, but not just in the 
sense of being able to mix and match paranu^ters. The 
goal of this project was to carry the idea of conri^urahil- 
ity a quantum k^ap into tJie fulure. 

Major Parts 

The Component Monitoring System can be segmented into 
three parts (Fig. 1): 

■ The rack and p^iramcter modules 

■ The computer module 
1 The display. 

This segmentation is not Just a tbeoretical way ol' looking 
at the Component Monitoriiig System. Tht* system can 
actually be sepaiated into these coin]>faii*nts. It is there- 
fore possible to place the parameter intjclules close to the 
patient and positi:on the display within sight of the anes- 
thesiologist, while the computer moduk^ can be totally 
removed tVorn the \dcinity of the patient. 

Computer Module 

The computer module incoiporates all the processing 
pow'er, the interfaces lo other devices and networks, the 
display controllers, and tirivers for imnum interface equip- 
ment. 

These fmvctional elements liave been broken into then' 
generic components, and then designed ajid implemented 
as individual function cards. The processing power, for 



example, is provided by an application flepernletvt i>uniher 
of CPL^ cards, working t ogether as a loosely coupled mul- 
tiprocessor system. Based ut>on a 16/^32-bit microproces- 
sor, each CPU card is an independent subsystem, ineliid- 
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ing a iarg<^ amount of static menior>' boot EPROM, and 
an interface chip for I he computer module's intenial bus, 
the message passing bus (Fig. 2). The ability to work as a 
self-contained, indepeiicteiYt entity was the smallest com- 
mon (ieiioniinator we wanted to apply to nur comjiuter 
module buildirig blot^ks. Because of this eoneei)tf prr^cess- 
ing power, interlace caids, or ilisplay etintrollers ran be 
added depending upon the customer's application. New 
function eards can l>e added by plugging them into the 
coiai>uler nioduie without inteifering with the existing 
eonngiiralion. 

Ljjeal rt^suuiccs of a function card, like static niemoiy or 
EPROM, cmi l>e extended by atkiing a bat ter^'- buffered 
stalie liAM card and an EFROiM card. They connect to a 
local extension bus, which is routed on the same connec- 
tor kis the message pjLssing btis, I bus allowing an identical 
design for all slots on thc^ i>ac kplane^ 

At first release of the Coniponent Monitoring System, 
there are 11 function t^ards. The spertmm includ<*s the 
above-mentioned pRjcessor and memory cards, interrace 
cai'ds to RS-232 devices and HP's medit:al signal distribu- 
tion network (Sl)N). bigb-resohiiiim nTonoclutmie and 
color display cont rodent, ami odier cards. 

Each function liad lo fit onto the standard function card. 
To make this possible, several apphcation-spe<iric inte- 
grated circuits (ASIC's) prtrvide high perfonnaiice in a 
minirnnrn «}f card space. Surface mount technology allows 
eonip<me!its in ver> small packages to be ununited close 
together directly on tla^ surface of a fmution card. The 
benefits of these new teclmologies are highly automated 
prodttction processes, reduced part count, miti incretised 
reliability. 

Message Passing Bus 

The message passing l>us represents the* backbone of the 
Component Moniftning System. 1 1 is by virtue u[ this so 
hit ion thai it was ft^asible lo imi>U^mem motlulaiity in 
sucii mi extensive fashion. 

The message passing bus is based on a message broad- 
casting system, ir> whic4i one bus paiticipant transmits 
intbnnation without ftaving to specify the address (if ttie 



receiving device, bestead » eveiy^ message is classified by a 
header, indicating tfu^ content of tbe message. A bus par- 
ticipant interested in a specific class of messages wxites 
the header (jf the information arid a ptiority into tJie sig- 
natiue RAM of its message p^ussing bus interface. Wlien 
the header of tbe message on the bus anci the header in 
tlte signature HAiVI match, the receiving card's message 
passing bus inteiface autuniatically loads tliat message 
hito its FIFO buffer. Depending on the priority assigned, 
the incoming hifomtation is flushed into either the 
bigh-j:>riorily or the h.>vV']>riority FIFO, tlierelvy preproeess- 
ing data for the VW. Comparing headers and luoving 
informal ion inttJ and out of the FIFOs is contjollecl by the 
message passing bus interface chip with no interaction 
from ttie data jUTJcessing device. Fig, 3 is a block diagram 
of this chip. 

Tlu' m^or advantages of this conceiJt aie ilireefoki First, 
messages only need to lie sent onci\ regardless of the 
fuunber of bus participants interested in the information. 
This guarantees that bus bandwifitb is not used men^ly to 
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duplicate messages going to miilLiple receivors. Second, 
the absolutjc^ bus bandwidth is defined by the speed of the 
message passing bus Interlace chip. The chip contiois tlie 
transmit and receive FIi*'Os and compares headers with- 
out support from the data processing de\1ce. hi essence^ 
tlie message passuig bus rliip is a buffer l>etween a 
high-speed bus and tiaUi processing logic working at valu- 
ing speeds, which should not be interrupted by every bus 
activity if it is to lunction effectively. 

The third major advantage of the message passing con- 
t^ept is tJiat new system cards can t>e added n> a uionitort 
and iiii long as they know the algorithm tV>r ill locating 
headers, they can actively paiticipate on tfie message 
passing bus. The bus has a decentralized arbitration algo- 
rithm, which detennines how each paTticipaul accesses 
the bus. Each interface chip incorporates arbitration cir- 
cuitry based on a round-robin-like system, assigning the 
bus on a rotating priority biisis, If tlie current bus master 
is level n, priority n - 1 will be given to the next interface 
requesting tite bus, and so on sequentiaUy. This guaran- 
tees that tlie bus is shtured equatly among all of the func- 
tion cards and is dynanucally distributed every time a 
message is sent. 

The message passing bus chip was desigrted ^is an ASIC, 
using a silicon compiler t ool to develop ajid simulate the 
circuit's functionality. 

Central Plane and Power Concept 

In the center of the computer module chassis is a 23-con- 
nector motherboard with press-fit sockets moimted on 
both the front aJid Urn rear. The message passing bus is 
routed to all 23 slots on this central plane (Fig. 4). 

Since all of the fmiction cards are mechanically identical 
in size, any card can be inserted into any slot of the cen- 
tral plane, thus making possible a wide range of configu- 
rations. The only exemption is the de-to-tlc converter, 
which always is locate* 1 in the same slot. This one cm'd 
provides the power for the computer uiodule, and is 
sourced with 60V directly from the C'omponerU Monitoring 
System display (Fig. 5). 

This soniewiiat unconmion power architecture w-as neces- 
sary to comply with the stringent leakage cuixenl limits 
Imposetl on uiechctil equipmerit. If the Component Moni- 
toring System wxtc to incorporate separate power sup- 
plies iu tlie display and the computer module, the leakage 
currents of both to ground w^ould be added together, mak- 
ing it very difficult to reduce this value to below lOD juA. 
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di.splay. 

The second reason for taking the power supply out of the 
computer module was the need to reduce the amouiU of 
heat dissipated in this small box to a minimum, so as not 
to jeopardize reliability. We therefore decided to have 
only one power supply for the entire Component Monitor- 
ing System, ^md to house this in the display. 

The Display 

Customers can choose either a uionoelironie or color 
14-inch display (Fig. 6)/rhese are high- resolution, nonin- 
terlacing, high-eontrast filsplays designed anrl l>uilt specifi- 
cally for medical applications. 

'10 provide CJUtslanduig wavefonu quaiityt the displays and 
the display controllers have a very high [lorizontal resolu- 
tion of 2048 pixels- At if us pixel spacing the human eye 
can no longer resolve the individual dots, so the curves 
appear very smooth. 

The displays also incorporate the Component Monitoring 
System coutrol patieL located beueath the screen. This 
control panel is the main means of interacting with \he 
monitor It consists of a membrane keyboaid, LED indica- 




Fig. 4. Computer module centra] plane and function otrds. 



Fig* 6* The display also incoTporates the conirol panel. 
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tors, and the human interface board, which is an HP-HIL 
de\ice looped through to the compuler module. 

The hardwan? architec-itire has proven to be one of the 
steps on the ladder lo success of the Component Monitor- 
ing System. With the adxenl of this new monitor, produc- 
tion has tM^n autoinaied and stream lined to an exieni 
unheard of for such a complex device as a paticnl moni- 
tor The parts standardization effort has resulted in a 
mere '30C» different items for the entire system. Our cus- 



tom eis can now have a state-of-the-art monitoring system 
that they can configure to their specific needs, and at the 
same tune be assured that their sjstem has been de- 
signed to stay abreast with technological or application 
changes for many years to come. 

Ackn o wledgme nts 

For their ouistiuiding results, for their endtirance, and for 
being a most eryoyahle I cam to work with, our thanl<s go 
[0 alJ members of tlie ComfKinent Monitoring System 
hardware group. 



Component Monitoring System 
Software Arcliitecture 



A modular design leads to a complex but easily manageable system that 
ensures economical resource utilization, 

by Martin Reiche 



HP Cnmprment Mtinilnring System patient modulos can be* 
mixed and malciuHl \o suii the appiicration, A module is 
added simply by plugging it into any free slot in the mod- 
ule rack. Wouldn't it bt^ ftuivenienl to handle all rumlii>us 
implementcci a^ st>ftware the saute way? Just find a free 
resource on any CPt^ card and assign the reqiured set of 
software building blocks to it. Use only £is numy t'PUs as 
neeessai-y. This arlicU* wiU show tliat this approach is not 
only viable, hut also ajiprnpriatc^ m tenus of hf>th develop- 
ment ecouomic*s and resource uiilization. 

Tlie basic idea of having building blocks with standard- 
iised interfaces that cwi be arbitrarily coinhiiieci has prov- 
en its power in many jirojects^ The Componetil Monitor- 
ing System paiicni signal acQuisilion system, compuler 
mcidule, and message passing bus concept reflect tliis 
idea welL 

This approach should also be pr<imising for software. 
However, a problem with sc^fhvare is its c(jmplexlty, both 
intenially and iu tcnns of interact ion with external enti- 
ties. ('oui[jnrieiU Mtnuioring Systt*m softwaie modules 
show significantly differeul pro Hies in resource require- 
ments, must share a multiprocessor real-time system in 
varying configurations without conflicts, have to act and 
comnumicate in a lueuuiugbil way wtili regard io Uie citr- 
n^nl cfut fig unit ion, and are iiupkuienlcd by dilTcrervt peo- 
ple in different places at different times. Tliis makes stan- 
dardizatiun rlifllt ult. 



We will show how these problems were overeome. both 
from an arehittx tural point of \iew and frotn a develop- 
ment envin>nmer}t perspective. As we proceed, we will 
encounter a continuously reeiuriug <itiestion in different 
contexts: How can we provide the needed creative free- 
d<mi for each i[\d(vidual, and al the same tittle n^anage 
their cooperation and integration into a coherent total 
solution? 

Layered Software 

As can be seen in Fig. 1, the Component Monitoring Sys- 
tem's functionality can be represented in a layered 
scheme. Similar lo existing t^omputer systems, the hierar- 
chy iias four levels: 
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Component Monitoring System 
Software 



Tolal amount of source code: 315 KNCSS 

Number of software modules deveSoped 30 

Number of module instances m an mstrumenl 43 

Number of message passing bus headers alloQated 

by the operating system BBO 

Average data ffaw on the message passing bus 50 kbytes/s 



* Tfie (PI' cards represent tlie basis for all data process- 
ing. They communicate over Lfie niessage ptissiiij? bus. All 
inLerfa{:es to extenial devices are fouiid here. 

' F'innware localed on these carcis provides services to the 
liigher layers ot the model. The rmiiwaiT implements 
eortiplex a]jplicaLion indcfiendenl fimrtions by ronvpil- 
in|^ cnnmumrls iuiil protocols inie Iiardwaie related sig- 
nals. Patient paianieter modules play a special role; coa- 
trolled by firmwai"e, their analog and digital hardwai'e 
converts the incondng patient signals into digital infor- 
iuadon accepted by the computer module. 
1'he operating system t^stalilishes the data patJi.s between 
the ai)j)lieation softv^^are modules on (lie one hand and 
the nnuware cm the other It contjols the execution of the 
ap[>lieation progrcmis, uKnes messages back and lV)iih, 
and continuously supcr\ixses the correct execulion of all 
functions. 

h is up to the applications to jTrovide the signal interjire- 
tation, compulation, alanti generation, and similar' func- 
tions and to st)piK)il user interact ion by drawinj^ windows 
and menus on the screen. How fmictions toe implem- 
ented in the lower layers is hidden from the application 
software modules. 

Modules and Messages 

All function can Is are designed so that they can be arbi- 
trarily combined over (he central pUuie. They cim trtuis- 
mit and receive messages and peifonii Uieir funclions 
regardless of t,he slots in which they reside. 

In a straiglitforward extension of this principie* tlie Com- 
ponent Monitoring System software architecture allows 
for arbitraiy distribution of software to the various ])r re- 
cess or cards (see Fig. 2), These self-contained aptjlictuion 
sofiwaje modules are the building t^locks of I he niodidar 
system. Each module re] presents a large furu*tional area — 
for example, the signal iirot essing for the bIot>d pressujc 
measurement with its atfillated aspects of alarming, con- 
trol interact ion> transducer calibration, and so on, 

Tb acfiievt^ this modularity, the current configuration is 
made transparent to the modules. Tliey will execute on 
any CPl_' card, and their sharing of a CTIJ caid with oth- 
er modules will not irUerfere with their operation, Tlie 
only way they can communicate is to trar^smit and re- 
ceive messages. As wiUi the message passing bus, the 
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Fig. 2. Application software moduies can bp assigned arbitrarily to 
tlie available CPU cardie tcj at thieve die jiiost €!Ct>noinical resource 
ntili7Mkm. 

origiiis mul tlestinations of Uiese messiiges aie iiidden 
from the appJication. 

This principle guarantees maximum tlexibiiily in reaching 
the reqidred functionality with a given hardware set. It 
also reduces develr>])ment risks, since at th(^ begmning of 
a complex ]jroject, neiOier tJie sizes of die mtxtules nor 
the resulting processing requirements can be accurately 
estimated. 

Inside a Module 

FYom a programmer's point of view, a module is com- 
posed of a numl>er of related C-language source files (see 
Pig. 3). There arc^ tliffereitt types of Illes. For example, 
PROG tiles ctaitain executable code ;uul Viiriaijle detmi- 
tions, ajul TEXT files consist only of character codes. 

Following a tiiLlored syntax, an ASCII fde called a module 
table pro\idcs comprehensive information about that mod- 
ule. Identification, communication behavior execution, 
and resoiu'ce requircuuents are sptuifled in this table, TIus 
file is converte<l to C source cotlu by means of an I IP-de- 
veloped compiler called mtc. In this way, a generic module 
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structure is defined. aJotig with a foimal description of 
interfaces among the modules and the rest of the system. 
These standardization rules are followed by every^ soft- 
ware designer, specify the guidelines for all interaction, 
and lay Lite foundation for a fully automated code genera- 
tion process. Thus, machine-processed specification ett- 
forces standardization. 

All C code Is then conipileti and linked, yielding a nunv 
ber of object files, which mv loaded imchanged into an 
EPROM card to l>e plugged into the computer module. 

Virtual Processor 

Tlie main characleristic of this software concept is that 
Oie current configumtion is in%Tsible to all of the applica- 
tions. They do not know which modules are assigned to 
which proces.sor, how many processors are available, 
whicli interface cards are present, or wliere messages 
come from and where they go. Therefore, soflvv^ue <ievel- 
opers must not make any assumptions as to whei^ their 
apphcations wili be executed. The only way mofhiles tu-e 
allowed Uj conmiiinlcate witli each other is by exchanging 
messages. 

These an> prerequisites for a tndy modular system in 
which applicatitms can be mixed and tnatched according 
to a predcfmed functionaliiy. \Ni\h ihis in mind, it is ap- 
propriate to defme an abstract progranuning model that 
we call a vMuat pwcmsor (see Fig. 1), This is a collec- 
tion of artillcial resources such as appUcaLiou priorities or 
data Imks. The \1muil t>ro(essor suiipHes the application 
programmer with all of the construction elemenls neces- 
saiT !o impiement futictions effectively and strnghtfor- 
wardly. Tiie prograjiimer viu} write functicins tliat process 
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Component Monitoring System 
Softivare Development En\iroiiment 



r.sTaikms nmmng md& tJ?e HP-UX 

t^aefming syste: ao oy « tocai ajt^ network Ttiis inciwies the C5psrai- 

(ng system, the c.-. tdgJs. and aH applications and documentat w Each 

vwjfkstatkm h^ mass storage ^id emuiauon lacittues IHP 640001 and couitJ be 
laitored to specffic needs 

Starting out witfi only a few itevelopers on a single HP 9?M Series 500. we ended 
yp wrth atKwt ten HP 90Q0 Series 300 systems being used by 20 softwafe engi- 
neers lowa/d the emJ of ti^ praject 

Ttianks to the pow^r and flexibility of these HP-UX systems, the continuous evoly- 
tion of the de^eiopment envtmnmeni proceeded very smoothly with respect to 
both Its extent and rts comprehensiveness. f€r ejcample. all generic data {8.§.. 

symtrel lables for messaee specification or tools tor process automation] was 

automatically updated on a1! machines. As a consequence, atanv pofni in time, 
identical prD[;esse-s were used pro}eci-wide— a preiequisite for smooth intefirahon 
of !!>e components 

Since atl application modules have the same form, it was possible to implmnent 
the standard generation processes only once. Besides the definition and evalua- 
tian of the module table, a ynrform prc^cess supports the implementation of any 
appHcation This turned out to be very helpfuL for despite the different functions of 
the modules and the varjous fnclinaiions or the developmeni engineers, one al- 
ways finds recurring featyres in any implementation This makes sofiware mamte- 
nance easier (or engineers other than the anginal programmer For exampte,. differ- 
ent language options of a module can be generated WJttiout touching any code. 

In our onvjronnient, a single engineer had complete responsibility ^or specifying, 
designing, and implementing each software module The actJvitfes of all of the 
developers had lo he decoupled as much as possible. Since enforced s-ynchronsza- 
iion would have been fntolerable. a maior requirement for the development envi- 
ronment was to support easy ger^eratjon of running versions at all involved work- 
stations Hem the Componenf Monfturing System's self-conhguration. 
implemented as the hoot process, proved vakiable All software modules are 
self-contamRd and independent During the boot process the modules are initiated 
within the current run-tnna env iron men t This environment can atvyays he tailored 
in meet the needs a It he module under construct ion 

The integration process is always e^Kecuted the same way. The current versions of 
the operating system ar>d other modules are collected from the workstations on 
the LAM and are toaded into the current work environment A configuration table 
then assigns the modules to CPUs m such a way that each module under construe- 
tion runs on an emulated CPU. Symbol tables zan then be corrected beforehand to 
allow for symbolic access, in all variables and functions. 

In summary, the extensive effort invested in lite development environment and 
boot process has been very beneficial lo the entire development and maintenance 
process, as well as to the product s qualny. Other projects leveraging from the 
Component IVIomtOfing System platform have profited and will continue to profit 
from this comprehensive and comfortable development envirDnment. 



messages without fiaviiig to piiy aiti^nlion lo li()W the iu- 
roniuition is distrilnifed. (^nicciJts such as intcrtnpis, liisk 
cunH'oi blocks, and flu^ message iJiissjug tuts r hii> can be 
ignored by tlu» ptTj^tanuitPFt wlir> is frpc t(j com cut rate ou 
tlic medical upprication. 1'has, the application pm^raui- 
nuns ta.sk is to convert the specific functions into pro- 
grartts Ih^il can nm on tlie viJlnal |)io<'cssor, and fhe ofver- 
ulhtg systcuis task is to sU]>pot1 this jinjgtani incj<]ule by 
mcatis of the curroul hardwait^ configuiiition and ensure 
that any two appU(alh)ns on a singU^ (T\^ do tiol iiilct*- 
ferc> witii okxch other. 
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Tte features of (he \ir1ua] processor are defined very 
formsdly, and (he application programmer ran only build 
on tliem. The interface specification of a module with 
respect lo the virtual processor is found in the module 
l^ble and is expressed in terms of the virtual processor. 

This abstract model and its formal presentation have 
proven to be extremely useful, both for separating tasks 
within the developmen! process, and for autrntrnting th(^ 
i n t egral ion proce^ss . 

ExecutdoiL Model 

Eveiy module^s program code can he considered a set of 
routines forming separate execution trees. The entry rou- 
tines, that is, tJie roots of the trees, can be executed after 
the completion of a certain time period or upon reception 
of a message (Fig. 4). Since funrlional areas within a 
module may have different precedence requirements, ex- 
ecution trees ran he assigned to one of several applica- 
tion j)riorities (see Fig. 5), For example, continuous wave- 
form processing has the highest prionty assignable, 
because it must process a batch of samples every 32 ms. 
and thus may delay the execution of all other functions if 
given a lower prionty. 

The lotiil coniputmg capacity of a certam CPU may be 
disirihuled among several execution ireeis witliin several 
modules with several priorities. The overhead generated 
for context switching is minimal 
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Fig, 5, Application module software can be thought of as a .set of 
execution trees These are assigned to appiicaiion priorities, which 
are virtual processor resoyrc^. 
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Fig, 6, P]ver5^ message has a f onipositc symbolic identification, 
which is evahiate<l at boot lime, when message headers are allo- 
cated. 



The application programmer specifies the priority of each 
execution tree. At run time, the execution time is parti- 
tioned externally to the niodulep without effecting iia 
functionality. The programmer also specifies the tmioiaU 
of execution time required. The operating sysleni guaran- 
tees every application the timely execution of each tree 
and checks this in a continuous fashion. This is essential 
to the safety of patient monitoring. 

Communtcation Model 

As already mentioned, communication among software 
modules and interface c*ards is iniplemented as an ex- 
chimge of messages. Message routing runction.s reference 
a 12'bit header, allowing for a ni*iximum of 40J)5 different 
data streams. It would have been possible to assign all 
headers project-wide in ativance, hut the Component Mon- 
itoring System employs a more elaborate process for es- 
tLablishing data paths. Every message has a composite 
(six-field) symbolic identification assigned. This is eval- 
uated at boot time w^ben headers are allocated (see Fig. 
6). Modules transmitting or receiving messages specify 
this sjTiibolic identification within their module tables. 
This method allows the implementation of some Lmpor- 
tant concepts. If modules are installed more than once, 
say for multiple pressure lines, multiple similai- data paths 
have to be established appropriately. This can he tlone 
externally lo the modules at boot time simply by counting 
the source numbers shown in Fig. G. Also, related mes- 
sages can be coUeeted into message classes by assigning 
identical keys, for example to the type field. Each mes- 
sage of a specific class then shares a predefined struc- 
ture. 

Programming with message classes represents a pow^orful 
method for dealing with configuration dependencies. The 
operating system supports broadcast messaging in a very 
convenient w^ay. For example, all alarm messages gener- 
ated by various sources are transmitted in messages of 
type At ARM. Tiie central alarm management facility — an 
application software module — can spec i 5' Ihat it w^ants to 
receive all alarm messages and then process them in the 
order that they appear. Losing wild-card specifiers for the 
unknown fields in the symbolic identification keeps the 
module code receiving broadcast messages regardless of 
tlte current configuration. Blocks of memory for class 
menibers can be requested with a simple entr>' in the 
module table. Tlie configuration dependencies are then 
resolved at boot time. 

Besides broadcast ing, tJie Component Monitoring System 
operating system uses two otlier important types of coni- 
munication: slatic point-to-potnl and dynamic point-to- 
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point. Static links are private communication linky be- 
tween two entities, most notably ^ipplication software 
modules and interface cards. Dynamic links are valuable 
wl)en one resource is used by different application soft- 
ware modules at differeinl times. A teniponiiT,' \\Tile to a 
screen area or the reading of sofi keys are extmiples of 
this concept, t'lasses of dynamic link nodes can be de- 
fined usiug the mechanism described above (link nodes 
are entry points mto an application softw'are module 
whose afniJated message is of some ty^^e specified In the 
receiver's module table). Fig. 7 summiirizes how Uiese 
conunupication t>pes are built on the message passing 
bus broadcast facility to sene the upper application level. 

The standard pai'ameter interface represents the backbone 
of patient data comniimicaliou within the Component 
Monitoring System. It Is a set of class definitions thai 
forms a kind of logical data bus on whicli all t>alieut data 
processing modules cart broadcast their data- Any receiv- 
er can then operate <jn waveform, nmneric, alarm, or oth- 
er messages in a conipletely decoupleti Qishion. 

Automated Configuration 

Modules cotiiribute to t he system's flexibility only it their 
handling Is stntple, compiirable to the ease of handling 
patient parameter mocluk^s. To achieve this, ihv tinujio- 
nenl Monitoritt^ System developnienl environment makes 
heavy use of automated processes, acting on formal inter- 
face descrii^t ions. The module table, IVjr examjjle, is com- 
pose*! of tjie tbimal specincatiotis relating lu the specific 
moduk\ Wlicn specifying conuuunication behavior imd 
executiort reciuireinents, the progranuner cmi reference 
items of inlertLSt by means of symbolic names — ^Uie same 
names that can be found in the program source code. 

As h>ng as the system is not po%vertHJ, all h aid ware and 
sofI Wiue components appe^ir unrelated. The computer 
module cards aie all connected electrically, but no logical 
data path is apparent. The CPUs iire ''empty" (Fig. 8a), A! 
boot, a monitor configuration table locatecJ on the central 
EEPROM tells the boot process how to aiTange software 
modules on the CPU cards (Fig. 8b). Using the nu>dule 
tables in the individual modules, the boot process binds 
the modules into the run -time system. After the fjrogram 
code has been transferrt^d to the CPl^ cards atul all con- 
figunitifjn dejKMulent <lata stnictures have been itiitialiiied, 
all mi>dtilcs will operate as expected. More Ihtui 40 a^jpli- 
catioti software mod tile instances are installed in tht^ 
Component Monitoring System. 



In this process, the module tables supply all information 
neccssar>^ to insfall Uie data paths. In the fusl step, reser- 
vations for message passing bus headers are accepted. All 
references to communication coiu^epts such as message 
classes can then be resolved. The process is analogous to 
the link process for computer object code. More th^m 800 
message piissing bus headers are allocated by the boot 
process; this gives an idea of the amoimt of communica- 
tion that is required to operate the system. 

Delaying the linking of software modules tmtil the boot 
t>rocess has, among others, one imporl<mt advantage: it 
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allows conriguratiofi indppendent impk^mentation antl an 
ease of software fiiaintenanre that is normally true oniy 
of hardware elements. 

Conclusion 

Both the software design and the C'omponent Monitoring 
System software t!evelopment environnient fsee page ir>) 
placed great emphasis on decentralization tmd decoupling 
and on the stand tirdizat ion and forinalizaticjn of interfaces. 
The latter provides tiie opportunity for comprehensive^ 
autontation, which in turn shows sij^nificant advantages: 

• Automation of all external activities sii|:)|jor1s a smooth 
integration of each module into the total solution. It elimi- 
nates communication problems within the development 
team by separating rcsponsibililies atid esrablisliing non- 
corruptihle entities. 

• Automated processes Lu^e rehable and efficient . Tjiey only 
have to be implemented once, and future users do not 
need an in-deptii understanding to be able to use tJiem* 

• Automated processes enforce consistency, De\iaticns 
from a standard are prevented by tJie tools. SpeciDcatiion 



flaws quickly betvome apparent . The overall system re- 
mains consistent. Tins is an important contiibution to 
software Quality. 

Automated proctesses maintain flexibility The evolution 
of processes can be coordinated centraliy, with only a 
few engineers involved. Users are affected to a much 
lesser degree. 

A project of the magnitude of the Component. Monitoring 
System software development cannot be managed in a 
reasonable way without a very high degree of automation. 
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Component Monitoring System 
Parameter Module Interface 



This interface is the link between the component Monitoring System 
computer module and the patient parameter modules. It provides fast 
response, optimum use of the available bandwidth, configuration 
detection, and parameter module synchronization. 

by Winfried Kaiser 



The parameter module interface of the IIP Component 
Moniioring Sy stent Ls the inten connect ion between the 
computer module anti the module rack. Ttie rruKiule rack 
can house a wide rajige anti a ^■a^yillg number t>f parame- 
ter modules. By means of transducers attached to the 
patient, the parameter motiules measure the patient's vital 
si^s. These devic es include the ECG, lemperal.ure, and 
recorder modules, and many others. 

The major challenges associated with the dcsi^ of the 
parameter module interface can be summarized as fol- 
lows: 

The system must tK> able to support comnuuiication be- 
tween the rack interface card in the computer module 
mul a varielv of parameter modules that may differ in 
suc*h chjLiact eristics as the sampling rate of the analog 
sigttal, the numliet of signal input or outptttchaimcls, the 
kind imd amount of data that, a paramelt^r module re- 
ceives from \\w ri>jut)U(er mcjdule (eontn>l data) or sentb 
to the computer module (status data), and mechanical 
size (1, 2, or 3 slols wide). 

Oicoding Logic (Gate Arraj^) 




M«isage 
PiSsIng Bui 



• It is a requirement of some cf iniral applications that cer- 
tiiin wavefonu samples lie measured and made available 
at an analog output with an absolute delay of less than 20 
miili seconds. 

• It must be possible to plug any paiimietcr module into 
any slot in the module rack. The system must identify the 
parameter module and its [josition within tlie rack (con- 
fi gu ration dele cl km ) , 

• The conmmnication link of a system ur^der power must 
not be influenced by plugging in or unplugging p;irameter 
modules or even entire racks. 

• The parjmieter modules must be synchronized with each 
other 

• The link must support tiie detection of defectiv^e devices- 
Link Design 

'fhe rack interface card in the computer module lias one 
eonnector to inlerfare to as mai^y as four moduie nicks. 
A modulo rack houses a maximtun of eight single-width 
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modules. This means that up to 32 p3:irameter modules 
can be attarhed to one rack interface card. 

Connections are established to each of the 32 slot^ by 
means of five address lines (see Fig. 1). Using these ad- 
dress lUies, liie decoding logic in the addressed module 
rack connects one of that rack's slots 1 o the receive and 
transmit Uncs of the rack interface in the compnter mod- 
ule. 

The serial interface of the 80C51 microcomputer (inte nial 
IT ART, full duplex, 5(K)-khaud) is used for conununication 
between tht^ rack interface cai'd antl the addresst^d param- 
eter module. Because of the fast response tune requue- 
mentj it was decided Ihat the pjirarneter modules should 
transmit their infonuation <jne sample a! a time. The rack 
interface gatlien^ all i>iu'imieter samples over a period of 
32 ms and forms them into the corresponding message 
passing bus data. 

Communicatian Protocol 

Tlie rack intt^rfate ron I roller starts the communication 
witti the paramt^ter modules with a special identification 
cycle. All possible rack slots are addressed, and a special 
control b>le reqnesLs identification. A connected module 
responds by sending its de\ice identification, hardware 
and Gnnware revision, and other pai-anieter-s pecif ic data. 

Using this identiH cation and an internal reference table, 
the rack interface cfjni'^^iles s.11 necessEn^ dRtii H.bQUt the 
connected device types. This includes each device's sam- 
pluig rate and its number and kind of transmit atid re- 
ceive bytes. After scanning all of Ihe slots, the system 
knows which parameter modules ;u'e available. 

Special digital logic together witli a simple connected/ 
not-connected connector pin inside each parameter mod- 
ule enables the rack inlerlace to recognize wti ether or 
not a module is plugged into any slot^ or wlit'ther a mod- 
ule is defective. If a parameter module is connected^ it 
responds when it receives tlie ctjntrol b>1e from tlve rack 
interface. If a module is not comiected, the incoming hyte 
is sent back to the rack interface card without any delay. 
If there is no response at all a defective module Ls recog- 
nised. 

Scan Table 

After the system determines which paranieier modules 
are present, a scan table is geneiated in the rack inter- 



face to desciibe and control all subsequent conmlun!(^a- 
tion. The scan table consists of 16 2-ms time slices. The 
table entry for each time si i ere specifies whicli parameters 
are polled during that time slice (see Fig. 2). 

The arrangement of the scan table depends on the s|^^ 
classes of llie parameter modules c(}nnected. There are 
five speed classes based on the sampling rate of tiie pa- 
ranieter modules: 2-ms^ 4-nis, S-ms, l(i-ms, and 32-ms. The 
2-ms parameters are entered in each column of the scan 
table, I lie 4-1 ns parameters in eveiy other column, and so 
on, A special algorithm guarantees that the entries are 
made so that each device is addressed at fixed intervals. 

The free part of the scan table is used to address slots 
that have no modules inserted. Wtien a paianieter module 
is plugged into the rack il is iirnnediately recognized and 
activated in the scan tabk\ which contains the supei^et 
of all parairieter modules that are allowed, A module that 
is removed from the rack is deactivated. Thus it Is possi- 
ble to connect and tiisconnect any parameter module dur- 
ing normal nionitoruig. 

Analog output devices that need a fast response lime are 
entered at tlie end of each time slice and receive the data 
from the selected parameter module within the same* time 
slice. Tlie total delay from input to output is less than 2 
ms (see Fig. 2). 

Parameter Module liiferactlon 

Wlien a parameter mothile is addressed by sending it a 
ntessiige (receive intemipt), li responds immediately by 
traiisniitting a j:>rederinetl internal dat^i lilock, typically 
consisting of waveform and sUilus data. After the irans- 
missionj the panmieter module starts an analog-to-digital 
conversion cycle of the patient signal or perlorms other 
tasks depending on the control informatioji in the re- 
c^eived message. Tlie result of the analog! tj-fiigital conver- 
sion and status infonnation are stored into a module's 
internal data block. This data is transmitted the next time 
the parameter module is addressed. Since conummicatlon 
with a particular device always takes place after a fixed 
interval, the module cxm synchronize UsqU' with this poll- 
ing sequence. 

At the 500-kbaud datn rate of the parameter module inter- 
face, a typical communication cycle witli a parameter 
module with one wavefonn takes about 120 microsec- 
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onds. When communication mlh one module has been 
completed, the next de\ice in the scan table is addressed. 

This procedure ensures both optimum use of the available 
bandw idih and ^-nchronizadon of the parameter module 
and the rack interface card. 

Smnmarj' 

The parameter module interface represents a ver>^ flexible 
solution for connecting a wide \ariet>' of it^odules to the 
Component Monitoring System computer module. Al- 



though the requirements addi^^sed by the 'mterface are 
complex, the final implementation is both versatile and 
rugged, and was kept relati\^ely simple by integrating 
some of the decoding Ipgic. 
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Measuring the ECG Signal with a 
Mixed Analog-Digital 
Application-Specific IC 

Putting the ECG data acquisition subsystem into a Component Monitoring 
System parameter module mandates high-density packaging and low 
power consumption, and was only possible by implementing major 
elements of the circuit in a large mixed analog-digital ASIC. 

by Wolfgang Grojjsbach 



Nearly everyone Ls familiar wil h or^e of thp ninst impor- 
lant medical paranietpi-s — i\w tneelro^ardingrani. or E('G, 
The electrical voltages created by ihe hean have been 
wc^Il -known to fhe nipdical romnninity for nearly a rentu- 
ty. h\ I he begin rung rhe ECd wiis measured by sensitive 
gatvanomett^i-^ with the patients hands and feet placed in 
vessels filled with saline solution, Improveuients in the 
assessment of diagnostic ECG signals have been closely 
related to I he evolution of electronics, great strides being 
matie when aniplilying devices such jls vacuum tuhes and 
later transistors t)ecame available. Today, low -noise oiiera- 
tional aniplLTier circuits are state-of-tiie-art for ECG signal 
processing. 

Physiol ogicaliy, the polarization and depolarissation of the 
heart s muscle mass creates a three-dimensional electrical 
field dial chaiiges with time. As a result, voltages can be 
nieasured on the surface of the body that re j) re sent the 
pumping cycle of the myocardium. A strong effort has 
bt^en made to standardize the points at which the volt- 
ages should be measured. TUv most widely used are three 
differential voltages: From right arm (RA) to left ann 
(LA), from lA to left leg (LL), and from LL in RA. Tht^se 
voltages cire known as ECG leads I, 11, and ill. The rig tit 
leg eleetrtide (RL) acts as the neutral pole in ttiis systetn. 
Tliis configitralton is kn(jwn as the Eindhoven triangle 
(see Fig. 1). 



ECG Signal Characteristics 

Ttic^ arnplihide of dic^ IKX; signal as measured on the skin 
rtmges from 0.1 niV to 5 mV. The frequency extends from 
QM U'A lo \m Hz. PhysioJogical signals hke the KCXi dif- 
fer frtnn artificial signals in that they are not reproducible 
from oiu^ time segment to another, 'fhey are more statisti- 
cal in nature iuid have laiger variatiotKs in signal charac- 
teristics than, say, a signal generator output. This (ilaces 
additifmal rt^quirement.s on the measmemc^nl system, espe- 
cially the analog inintt stages. Although Ihe average ampii- 
tude is only around 1 mV, there are large dc offset voh- 
ages bec*ause of eledrociieruicil processes between the 
electrode attached lo the patient and the patient's skin. 
These ran be as high as ±500 mV. Also, the contact resis- 
tance between an electrode and the liody surface can 
vary widely and reach values around I Mil. In addition, 
the system must be capable of detecting thai an (Mecirode 
has fallen off the patif*nt. Perhaps the laigest constraint is 
the presence of 60-liz or r>0-!lz pow(*r line noise. Tlie 
human body acts like the midpoint of a capachive divider 
between one or nnue pt>wer lines and ground. Thus^ com- 
mon^mode voltages as high as 20V p-p can be superinv 
posed on the body. Kruiiiriathig this source^ of noise is (me 
of the m^jor tasks of an BOG amphller. Fortunately, the 
ECG signals are differential signals whiU* the i>ower line 
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Pig, t. Phccmfmi ofECG ulecn'odcs. The lolois of tlir cabling 

sysluni are slLiiidardizecl. The right le^ (\iL) connectjon ants as the 
nfnimil pnle, (In rEUjnttoring rj.;3|>lif?it.i<,ms iJio Rl, arnl hL r'lhniscrTifmsi 
are of I en as shcwTi hem mu\ iiol nii J he legjfi.l 

voltages arc^ conimon-n"iod(\ so Lhc noise can be reduced 
witii differential anipliiiers. 

Another requirement resuh-s froni artificial pace pulses 
used lc> slim u late the heart l)eat of some patients. Paf^e- 
rnaker (h^vh ('^^ are inii>lant od into the rliest, generating 
sumiil pulses up to IV p-p at frequeneies in the kilohenz 
range. Pace pulses are superimposed on the Et G signal 
and have to be detected to differentiate them from the 
peak value of the ECG signal, calknl the QRxS complex. 
This is inqxjprtant bec^aiLse the hcartrate measur cement is 
based on this QKS signalt and an incorrect interpretation 
would result in an incorrect value. 

In emergencies when the heart stops beatuig (ventricular 
fil^rilladonj, a commonly used pnjcedure is to apply a 
voltage pulse of al>ou! 'i kV p-p wilh a 5-ms duration to 
synchronize the nemal stinuilus of tlie heart's nuiscle 
mass antl bring It back to rumnal opejaiiiig conditions. 
Because of the high voJtiiges neeiled to (iefi brill ate a pa- 
tient, the inputs of the ECCl circuit nuist be protected. 
tJther sources of noise are electrosur^ery de\ices, which 
are used in operating roonis as elec Ironic scalpels. These 
devices contain high-frequency currents in the megaliertz 
range. The high current density at the tip of the ele<1rode 
coagulates the proteui, Ihereliy stopping bleeding. The 
fX'G motlule nmst provide additional filtering against tins 
high-frequency noise. 

Integrated Solution 

The design goals lor the Component Monitoring System 
ECG module included reduced cost, reduced siKe, mini- 
immi power consumption, and increased reliability and 
fui^ctionaiiiy compaied to the current patient monitor 
generation. 

The target size was a single-width parameter module. This 
module measures only 99. (j nuu by 36 mm by 97.5 nun 



(3.9 in by 1.4 in by 3.8 in). It was therefore obvious tJiat 
we would ha\e to use surface mount technology to meet 
the size objective. In addition^ it soon became apparent 
that a large percentage of the electronic circuit would 
have to be int^egrated in silicon if the entire device was to 
fit into a single- width module. This and the need for cost 
reduction on such a high-volume parameter module as the 
ECG niodule clearly mdicated tliat an application-specific 
integral e(i cirrtiit (ASIC) would be the appropriate solu- 
tion. 

The investigation revealed that the chip size we had in 
mind and the mixed analog-digital desigr^ were real chal- 
lenges for a fully custom ASiC. Our ijlan was to integrate 
the following function blocks uito a single chip: 

♦ Full three-channel ECG amplifier with various filter 
stages of bo\h analog and switched capacitor t^pe 

* Precision resistor n(^tw^ork for the weighting ftmction 

♦ Three-channel lead select multiplexer 

♦ Precision differential amplifiers with high conmion-mode 
rejection ratio 

• Eight-channel multiplexer for sequential scanning of all 
analog signals 

• Bandgap voltagt* relerence 

• 10-bit iuialog-t.o-digitaJ converter (ADC) 

• EHgitaJ control logic for switching filter comer frequen- 
cies, multiplexers, and other circuits 

» Serial interface to connect the chip with the surrounding 
circuits. 

To be able to integrate all this, a 3-pm CMOS process 
was chosen. It is a p-well LOCOS process with polysilieon 
gates and iori irnplantatitjn. NMOS and PM(.)S fleld-eneci 
trartsistcjrs are combined. Also available are n-channei 
JFETs anci pnp bipolar transistors. The tlun-tilm resistors 
are laser trimmable to witliin 0.1% niatching. Available 
cells include ,1KET operational amplifier, liipolai' opamps, 
switched capacitor filters, S-bit to 14-bit artalog~to-digital 
and digital-to-analog converters, and sampie-and-hold am- 
plifiers. 

The Electrocardiograph ASIC 

The* basic hnictions of the ECG c ircuit can be seen in 
Fig. 2, which shows one of the three independent chan- 
nels. The inputs are switched to the RA and L:\ elec- 
trodes £is active inputs. The RA £uid LA inputs of the chip 
me connected \o the ijatient. Protection circuits against 
ESD and tlefibrillatoi' pulses and c undent-limiting resistors 
are pro\ided outside the chip on the printed circuit 
board. JFET input opamps amplify the signal five times 
and act us higii- impedance input buffers, A precision re- 
sistor network (Wilson network) sums I he various elec- 
trode voltages to achieve the standard voltages for the 
different ECG selections. The multiplexer selects the ap- 
propriate lead voltages from the resistor network. Tlie 
10-kHz low -pass filters act iis pre filters for imti-ahasing 
purposes to reduce the lugh-frequency components in 
case an electrosurgery unit or other high-frequency noise 
source is couphng into the module. These ai'e analog fil- 
ters. They protect llie switched capacitor fillers with their 
lime-discrete sampling system against unwanted aliasing 
disturbances resulting from ItighTrequency noise. 
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JFET Input 




night Leg 



Fig, 2. Bimc stnictiire of the ECG 
ASIC (one of three channels), 



The RL input acts as the neutral pole, but is not direclly 
connected to analog ground. Il is the low-impedance out- 
put stage aii an inveiting simtnilng ainplifipr (called the 
riglil leg drive) which serv^es as a jeedback circuit, furthci' 
reducing common-mode power line voltages. The com- 
n^on-mode signal present at the output of the lead select 
multiplexer Ls phase inverted and fed back to the patient, 
thus being subtracted from tile con noon-mode voltagt^ 
present at the inputs. This helps eliminate unwanted pow- 
er line noise. 

The difference between the tw^o selected eiectrode signals 
is deri%'ed in the differential amplifier section, which has 
a gain of one. ITp to that point, aU gain variations and 
tolerances iilTect the comnion-ntode reject iojL Therefore, 
these stages have lase-r-trimmcd resistors where appro- 
priate. 

At the ouipuls uf tlie difTerential ajuplitler in eacii of tlie 
three channelSj the signal path is split into two parts. For 
the two main channels, the auxiliary' path goes out of the 
integrated circuit to the pace puist^ detector. The pace 
pulses iire identified by tiieir iiigfier- frequency content in 
the range of 1 to 4 kliz, but ordy liie presence of a pace 
pulse has to be detected, not the time dependent signal 
itsell Therefore, it Ls unnecessai> to ct>nslruct the whole 
signal path with this large bandwidth. After the pace 
pulse detector output, low-pass filtering of the ECG signal 
begins. 

For ECG filtering, a mininiuni lower corner' IVequency of 
0.05 Hz is required. Tire large c*apacilor and resistor val- 
ues needcfi c[)u]d nol be integrated and therefore the 
signal Is routed from the chixJ into external filter sections, 
one for each chaimel. By means of internal switches, 
three low-end comer frequencies (0,05 llz, 0*5 Hz, ^,5 Hz) 
and two high-end comer fiequencies (40 ILs and 130 Hz) 
can be selected. 

The signal flows out of the chip, through tlie external 
filters, and back into the cliip. It ihen goes throtigh the 
main gain stage, which has switchable gain of 40 or 160 
depenfling on the signal amplitude and the resolution 
needed on the screen. After piLssing the gain sta^e, the 
signal is filtered with a second -order switched capacitor 
stage to achieve the cxjmer trequency of 1:30 Hz with as 
small a t.ole ranee as possible. 



The three analog channels descrihed so far are connected 
to the inputs of a one-of-eight nnilti|)lexer, which sequen- 
tially scans these three chamiels and five auxiliary- chan- 
nels every 2 milliseconds. The output feeds into the ADC, 
a 10-bit converter that has less than ±1 LSB deferential 
nonlinearity and a conversion time of 20 ^s. An 
8-by- 10-bit dynamic random accx^ss rneiiior>' holds all the 
convej'sion results temporarily until Lhey are transmitted 
via a pa rail el -lose rial converter oul of the clup to the 
nrot[tde microprocessor, hi ihe opposite direction, all con- 
trol infomiation is transfened into the chip over this seri- 
al interface and latched. The use of a serial data conver- 
sion scheme made it possible to use OJily tluee output 
lines and a 28-pin package. 

Fig. ;J is a photograph of the ECG ASIC clup. 

Pace Pulse Detection Circuit 

The dital pace pulse detector is also an ASIC, hs iuialog 
pads are buih entirely in swilrhed capat itor technology. 






1 




ir%;n 






Fig. 3, IMkrjtugi'upii oj' the Eftf AtilC waftT. 'flK_^ uiiiulug hJiirtirfriH 
i ovcM" much larger areas dian tlu' \\{g\\.w\. parts. 
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Fig. 4. MKini ECG module printed 
(■\Tc.uil baanjs. T\w large capacitors 
on tiie left board are pari of the ex- 
terna] filter stages. Tlie ECG ASIC 
is just in front of these capacitors. 
The PPD is to the Jeft of the ASIC. 
Tile right tjoard contains the dij^itaJ 
parti; of the module. 



This had the advantage of avoidir^g laser trininiing, mini- 
mizing wafer area, antl ihtis redut ing cos(. This chip gen- 
erates two logir output signals for each channel, indicat- 
ing whetlter a pace pulse with eitJier positive or negative 
polarity is present in the input signal. The information is 
polled by the microprocessor and sent to the algorithmic 
software. 

Tost Considerations 

It was ciear Irotn ihe beginning that testing the ECG chip 
would be a challenge because of the large ninnber of 
parametet^ to he measured. The specifications describing 
the functionality are split into two parts: intenial and ex- 
ternal specifications. The internal specifications can be 
tested with wafer probes and help tbe vendor optimize 
the prodiit'lion process. They are consisttmt with the ex- 
ternal specifications, which Eire measurable from outside 
the chip and are accessible to the customer. The external 
specifications are the lir^k between tht^ ASIC design and 
the printed circuit boartl design antl were iiseti as guide- 
lines througliout the design anti vmfication process. Auto- 
mated test equipment hcis been set up at IIP to test the 
ECG chip via its serial interface. The same test equipment 
is used by both the veiHit^r and IIP lo leduee the number 
of false metisurements resulting from different measure- 
ment setups. 

Results 

Fig. 4 shows the printed circuil hoards of the Ml 00! ECG 
module. All components betw^eei^ the ECG ASIC (the larg- 
er one) and the input patient connector are for protection 
and filtering against defibrillator pulses, electrostatic dis- 
charge, and electrosurgeiy imits. The following tiible gives 
an overview^ of the two ASIC chips (PPD is the pace 
puJse detector); 



Item 


ECG ASIG 


PPD ASIC 


Die Sixe 


6.22 by 6.27 nmi 


3.43 by Sm mm 


Analog Ptinctions 


24 


12 


Digital Functions 


4 


2 


Number of Transis- 


-=^6000 


-^2000 


tors 






Number of Digital 


-550 


=200 


Gates 






Number of Pins 


28PLCC 


20 PIX^C 



Power Consumption 275 mW max. 45 mW max. 

Dynamic Range ± 3 V ± 3 V 

Overall Analog Gain 800 

Noise (referred to 2 Ii>B 
input ) 

The main problem that was faced in this design project 
was the complexit>^ of the system, which caused side ef- 
fects that w^ere not visible in the beginning. The die size 
was too big for normal packages, so packages with larger 
cavities had to be foimd, Tlie simulation tinie w^as longer 
than expected because of the large number of compo- 
nents inside. 

In summar>; the design objectives W'Cre met. The ECG 
perfonnance is state-of-the-art. and significtml reductions 
in cost, power consumption, size, and compuueut count 
w^ere achie\^ed in c*omparison to a discrete solution, 
which probably would have required a double- width 
module. 
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A Very Small Noninvasive Blood 
Pressure Measurement Device 



This small assembly covers the entire blood pressure measurement 
spectrum from neonates to adults. The packaging of the air pump 
assemblY makes several contributions to the objectives. 

by Rainer Rometsch 



llxe nonin\^sivp blood pressure niodule of the HP Com- 
pont^ni Monitoring System is a double- width paranieler 
module used to measure and calculate a patient's systolic, 
diastolic, and memi blood pressure. The method is based 
on inflating a cutT on the palieni "s ami mitU ali blood 
flow is supiiressed in this exirernity The pressure in the 
cuff is tlieri slowly deflated, and by using the QsciUomei^ 
rie measurement teclmique, both tlie high and low blood 
pre^ures-and the mean value can be determined. 

Physically the noninvasive blood pressure nnjdule cotisists 
of two parts. One is the electronic boai'd, which ccmtains 
the power snpply, the signal acquisition circuitry, and the 
interfa<*e to the computer motlule. The other is the puriij> 
ass<:unbly, which is respor\S(ble for Uie controlled inflation 
and deflation of the cuff. 

Requirements imposed on the pump assembly wrtg: 

• Low parts price 

• Minimum nuttiber of parts 

• Robust construction 

• Easy to assemble in the parameter module 

• Low power consumption at, the higliest posstt)le pump 
capacity. 

Because of the required size of the pimip ttssetnbly (it 
had to fit in a single- width parameter module S. arvti the 
need to reduce the nuittber of individual parls, a toudly 
new ajjproach was taken in the design of this mectiaiiieal 
part. The solution impleinenled is a self-contained func- 
tion block allowing a stringent separation lietween the 
electronic^ printed circuit board and the pneumatic system 
(see Fig. 1). 

The Pump Assembly 

'fhe pimip assembly ("onsLsLs of the pump and two valves. 
The pump is a membrane device driven by a dc niolon 
To meet the re(iuiremetHs of the application, the pump is 
optimized for hij^h ptnnping capacity and low air leakage. 
Air leakage is i* big <'onceni because flie volume in the 
cufl' has to ^ t' teflated in a liigbly rontrollcfi fashion. This 
is especi^'.y difflt^nlt for rteonatal applications, tjccause 
neonalr. cuffs have veiy small vnitnries. Wc> solvc^d the 
problem by incoiporating a re flow valve within the pimip 
module. This pressure valve opens at low flow rates, and 
tiieiefore does not increase power consumption. Tht^ ini- 
puitanl thing is that it seals tigiuly at a vejy low rcflow 
rate. 




Fig, 1. Pump a.ssf*mbty ni ttip Gomponent Monitnriiig Bysiern ritHiiJi- 
Vfisive blofid pre.ssurt^ tnet±j^ureninnt nsodiile 

The second elemenl In the pump iissembly is a pair of 
valves, flanged to a mat hined ahiminimn extrusion, Tvvo 
valves 'ATv Jieeded b> pn»vifle a fail-safe circuit that will 
comply with the safety requirements impose*] on noninva- 
sive blood pressure measurement de\ices. These two 
^'aives have consitteratjly diffcvrent flow ctiaracteristlcs. By 
autcjmaiically switching l>etwcH*n the two valves, one non- 
invasive blood pressure motlule covers the entire applica- 
tion spectnmi from neonates' cuffs all tht^ way lo adult 
tlugh cuffs. 

T^e aluminium extnision is designed lo noplace all ilie 
necessary tubing between the pump and tbt^ valves. It is 
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thereforp possible to flangp \hv niounltTl vaJvo cmtf) tho 
piinip without aiiy additional rubber tubing. This eontrib- 
iites to a part count reduction and smiplifies production 
dramatically. 

Tlip only connections thai have to be made with the 
pionp assembly are a iri-nmi-lcmg i'ubl>er lube to the non- 
inviLSive blood pressure connector in the paranieler mod- 
ule, and a power comiection to the electronic board for 
the dc pump. The nibher tube to the noninvasive blood 
pressure connector Ls esi^enUal because this flexible tub- 
ing detaches llu" pump from Itu^ the paranieier niodule 
housing and tluis ht^lps damp acoustic noise caused by 
m echani ( a 1 \1b ra t i on . 

Packaging 

The entile pump ^issembly is encapsulated in a poly u re- 
thane package. This relatively simple pait contributes in 
more than one way to the goals of the overall solution. 
All noise generated by tiie dc pump is muffled by the 
package to a degree that is acceptable in the hospital 
en\dioiinient. Tbe pump assembly survives the l-ni drop 
test because sufncienl kinetic energy is absorbed by the 
package to avoid damage to tlie mechanics. Packaging of 



this part for shipment from the vendor to HP has been 
minimized to a simple protective cover. 

The outline of the foam package is identical to ttie inner 
contour of the parameter module. Therefore, no additional 
parts are needed to embed the pump assembly in \he 
inner enclosure of tlie par-dmeter modide. The eliminalion 
of additional screws or clamps has helped reduce produc- 
tion lime mid jiari count. 

Conclusion 

Tbe ("omponeni Monitoring System noninvasive blootl 
pressure module meets all of the above described objec- 
tives. Because the pun^p assembly and the electronic 
board are delivered as i^rehibricatctl paits, itie totiil time 
to btiild the module has been reducetl to atK>ut two mui- 
utes. The result is a small, robust, self-contained noninva- 
sive blood pressure module, to our knowledge one of the 
smallest noninvasive blood pressure devices in the world. 
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A Patient Monitor Two-Cliannel 
Stripchart Recorder 

Small enough to fit in a double-width HP Component Monitoring System 
parameter module, this recorder embodies simplicity of design, a highly 
tooled mechanism, and sophisticated printhead power management 

by Leslie Bank 



The medical einironmenl requires a recorti of die care 
thai lias bceii given to a pLilient, bolh tor I he patient's file 
and as a legal document. For patient muiutoring equip- 
ment lilce the IIP f omponent Monitoring System, the re- 
cord has IraditionalJy i>een a conlinuous striji of paper of 
various widtiis. Aii t^xample of a it'c<ji<iing hum the Com- 



ponent Monitoring System's Iwo-channel recorder is 
shown in Fig. 1. Vig, 2 is a jjliotograph of the recorder 

in tlie past, the lins(>itril had three opU<:)iis lo provide rc- 
cYjrding capability tbr a patient, each or wliich was less 
tlian ideal: 
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Fig, I, T^'pit:al Uxo-cluiiuiei stripdmrl retordiiig of patjent. flata. 
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a mark l^ made on the paper. This, combined with the 
power jnequirenients of the motor and electronics, normal- 
ly would require much more power than the 6 watts that 
are available. In addition, I here can be no xentilation in 
the houfiing. Meeting the high-temperature specifications 
was difficult because of the internal heat generated by 
the power-consuming components. 

Ea^t of Use. Recorder operation should be flexible ro meet 
I he various medical applications. It should be intuitive for 
rhe occasional user Most of the Component Monitoring 
System recorder operation is part of the normal ctmtrol 
structure. Tlie difficulty for the recorder desigri team was 
to make the paper loatling easy while nol using any pow- 
er to aid paper feeditig. 

Reliability. Recorders, w^hich ha\'e moving parts that wear, 
tend to be less reliable than eijiiipment that does not 
have moving mechanic:al piuls. A simi^le mechanical de- 
Sign along witb high-quality components and a severe 
testing program resulted in a highly reliable product. 

Manufacturing Ease. This recorder was designed for 
higli-voluinc ;tssen\bly. Much effort was spent in minimiz- 
ing pad c<Hml, \n using the molded parts to i>erfomi nuii- 
tiiilc iunctions, in designijig adjustments out. ajid in iiiak- 
ing the instrument easy to te^. 



Fig, 2. Tlir fiProniiiuiipru Moiitlurini' Sysiem two-chaiuipl ret^order 

• f*urchase a recorder for vw^iy bedside. This is very ex- 
pensive in these days of cost containntent. 

• Use a ccntnu. shared reconien With nuich of the patient 
care given at the bedside, not having a recorder nearby is 
a dislincl disativatitage, 

• Mount tile rtM^rjnier on a cart and wheel it \o the berlside 
when ncfnlcfl This takes up too much of the available 
room at Ihe bedside and is also inconvenient. 

The Component Monitoring System philosophy of allowing 
ibe monitor coiifiguralion to cOiange with Ihe patient*s 
needs exiends to the rtM^ording funcrion. The two-chamiel 
recorder can t)e moved an>und like ;my other parameter 
module. This approach, along vvidi tfic re(|nirements for 
ease of use, high reliability, high pt^rlormance for many 
types of applications, low^ manufacturing cost, ajid low 
power led to \hv following st*l of nifyor specificat ious: 

• Size: DouhlC' width parameler module 

• Powder consunipt ion: Approximately 6 watts maximum 

• Number of waveforn\s: :l 

• Lines of character printing: 3 

• f*apen 5<J-mnvby-J0-m rolls {fan-fold paprr would not fll 
in the desired package size). 

These specifications resulted hi a uuniber tif major terlmi- 
c^ challenges. 

Size. Milling ihi* paper, motor mid drive mechanism, elec- 
uonit '.s, and suptioiling siructiu'c* inlt) a package of tliis 
size was a miyor accon^plishnient. 

Power Consumptlofi. Chemical therma! paper is used in this 
recorden A print head consisting of a lini^ar an ay of resis- 
tors is in constant contact with ihe paprr. When p<*wer is 
applied to ont^ of these resist ors, the resistor gets hoi and 



Mechanism 

Paper is k>adec! by opening a door and inserting the roll 
of paper itno the paper compartment. The paper is then 
threaded around a drive roller and pulJed taut, and the 
door is closed. As the door is t losed, a ami is engaged 
which low^ers tlie print head. The roller is driven by a 
stepper motor wliLrii is connected 1o the flrive roller by a 
drive bell. The rolliT is dr'iven when the motor turns. The 
fjaper has enough wrap aroimd the drive roller to ensure 
that it can be driven under the print liead. Enough bac^k 
tension must be pnjvided to make ihe ])a]icT track i>roper- 
ly, yel loo nuich tension irKTt^ases the motor torque re- 
*|uirements, whicti in tuni increases the power required. 
This tunied iiito an iiil crest ing design trade-off. St^aled 
l>all b(^arings are ust^l on tlu* drive roller to minimize 
tjower requirements while keeping paper dust oul of the 
bearings. 

T^^o iryeciion-molded frames fonn the cltassis. Tlie print- 
iiead atid drive roller are caiitured between the t^hassis 
halves, while thi^ mtitor, paper door, jiower supply board, 
and digital lioard are all mounied to the oulsick* of the 
chassis. Tlie entire assembly is enc^losed in a double- 
width module ctise. 

Electronic Hardware 

Tlie digital board contaii^s two Intel SOClOrj 10-bit niicro- 
contrtjllers which cunmnmicate with eacli oiher via a 
shan^l RAM. Bach microconl roller contains a serial port. 
The I/O jirucessor uhps its st'rial port to comnuuiicEite 
with the monitors computer module via the parameter 
module interface (see article, page 19), If receives digital 
conuuands, waveforms, antl text data from the monitor, tl 
interi'irets the commands and I ran s tonus the data into a 
tbrmat compatible with the print head. It also montlors the 
front -|)anel and door-ojjtm swil cites iuid the paper-out sen- 
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sur. TJ)e I/O processor commimicates the recorder status 
to the monitor. 

The other processor takes the information from the I/O 
processor and ships it to the printhead via its serial port. 
The energy applied t.o each resistive dot in the printliead 
is tighlly controlled by varying the print h(?ad strohe times. 
Tlvis ensures high-quality printing and long printhead life 
with mininial energy use. This processor varies the print- 
head strobe based upon printhead temperature, resis- 
tance, and voltage, which are measured by the onboard 
analog-to-digital converter. The mofor speed data is also 
sent to the motor drive chips, which are located on the 
power supply bf>ard. 

The power supply board transforms tlie bO volts received 
from the monitor into 15 volts required by the printhead 
and motor, and into the 5 volts requin^il by ftie loj|ic. This 
power conversion is perfomied by a switching power sup- 
ply with a typical eftlciency of 83%, The motor is driven 
by two stepper motor chips which, under t*ontroI from 
the digital boarti, tnicroslep the motor to jjrovide accurate 
chad speed will^ niinirual power. Tlic peak energ,v 
supplied to the printhead is provided by a iaige capacitor. 
In case of extremely heavy printing, the power to the 
printhead may sag. To prevent tlu.^ ICi-volt supply from 
sagging too much, a curreni liniiter is placed betwceri I be 
printhead energ>^ storage device and I be 15-voli supply 
Finally the optical isolators for the serial (Jala lines to 
the monitor are on tills t)oard. 

Printhead Control 

Character and grid generation are provided by the record- 
er. The selected characters and grid are combined w^itb 
the waveform data, raslerized, and sent to the printhead 



to energise a number of resistors (dot.s) in (he prir\thead. 
The printhead Is loaded tlu-ee times for each dot printed. 
If the dot has not been tired and is "cold", it is fired for 
all (bree loads. If the dot has been fired hi tlie last cycle, 
it is "hot" and is fired for only one load. If the dot has 
been ftred two cycles ago. It is ''w^arm" and is fired twice. 
This results in a historical firing of eacii individual dot 
and [precise temperature control of eac:b dot. In addiii<jn^ 
eacti nt' (he three loads is accomfjanied by a sinjbe of the 
printhead- Kacb strobe lime is varied based upon print - 
head voltage, temperature, resistance, and chart speed. 
For example, as the temperature of the printlvead in- 
creases, ihe amount of energy providetl to all dots de- 
creases. This lesults in a lower printhead tecnperatiire 
rise aiul less tiiermal shock to the tlol resistors, while 
providing consistent printing quahty. In addition to all 
this, die entire printed area is dithered up and dt)wn over 
time. This equalizes the use of all the printhead j'csistors 
and improves the life of the printhead. 

Ac kn o w 1 edgni en ts 

The ti^cluikiues presented here have resulted in ai^ effi 
cient fu'oduct design ftiat builds ut:>un the sirengtlis of the 
C'omponent Monitoring System. The simi>licity of design, 
highly tooled mechanLsm. sot>hi.stirated printhead twwer 
management techniques, and muc h testing have resnlted 
in a reliable, higJi -performance yet cost-effective solution 
for our customers. Much effoit and hard work w^ent int:o 
rnakuig this product happen. I cannot hope to thimk ev- 
eryone uivolved on the reconler project, but I would like 
to give special tiiarrks to (jcrry Patrick. Renee {Jlson, 
Waiter McGnnh, Chris Roth well, Jeff Berry, Doniinir Luc- 
ci, Marry Schofield, and Jim Larsen. 
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Patient Monitor Human Interface 
Design 

A design based on human factors leads to an intuitive and easy-to-use 
human interface for the HP Component Monitoring System. 

hy Gerhard livig and Wilhelm Meier 



The desi^ of the human interface for the HP C'omponent 
Monitoring System invoived a coordinated effort of R&D, 
marketing, and industrial design t working with valuable 
inpute and feedback from the principal users— the inten- 
sive care unit (ICV) nurse and the anesliiesiologist. Fig. 1 
illustrates the basic elements of itie design process for 
the human interface. 

Tlie lunctionality of the Component Monitoring System 
goes beyond the classiciil real-time patient moniroring 
functions. The monitor offers extensive suppoit for medi- 
cal procedures, such as canliac output and S-T depres- 
sion m\(\ elevation measurements, a powerful data man- 
agement capability wilh vaiious calculalion and report 
facilities, and a review facility for idanns and patient in- 
fonnation from ''another bed" usin^ the proprietary HP 
serial distribution network fSDN). Tliis functional com- 
plexity had to be hanriletl wilh a single consistent and 
simple operating stnicture so that it did not leaci tu a 
complex user iiiierface. Because it is a key element in the 
users ultimate buying decisicm, usability w^as a critical 
issue in the design. 
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EEvirouments and Users 

The Coniponeni Monitoring Syslem is used m a v^ety of 
en\ironnieivts. Including the surgical ICl'. the neonatal 
and cardiologj^ ICUs, and Uie operating room. There is a 
wide spectrum of users, including the nurse in the ICUs 
and the nurse anesthetist, the anesfiiesiologist, and the 
perfusionist in the operating room. 

The primary user in the operating room is the anesthe- 
siologist. Some of the tasks performed wre of a clerical 
nature, such as logging patient and life support de\ice 
data, obsenTng the moiiitor. and scarming the area. There 
art* also physical tasks, not directly related to the moni- 
tor, such as patient prepaiation, adnunistration of drugs 
and ntiids, and patient, observation. 

In the surgical and neonatatal ICUs, 909*j of users are 
nurses. The tasks performed by the nitrse include 30% 
clerical activities, such as recording rnethcal data, writing 
down and checking doctoi-s' orricrs, writing down tlu^ 
medicatiort i>laiL arid Hfling out tlu^ patient's nowshecL 
The other 7{^X> of the lasks fjc^ifomied are of a physical 
nattu-e, such as administering fluids and drugs, lakuig 
measui'ements, making physical examinations, ensuring 
patient liygiene, and pt^r forming medical procedures. 

In most cases, nurses and physieians have no computer 
experience. It can be exiieclcd that numy of them will 
have doubts about ibe introduction and use of comt>ut- 
er-based monitoiing ettuipment. Therefore, it wa^ consid- 
ered atlvisabk* not io make the Component Monitoring 
System look like a ctunputer 

The main focus is on the parienr The niu^es and the phy- 
sicians do not have time to interact extensively with the 
monitor They aj-e in a crf)wded and stressful ernirtjn- 
ment, where it is not unusual to encounter critical situa- 
tions ret|uiring immediate at^tion to prevent degradation of 
the patient's situation. Cluucal pei-sonnel also face a wifle 
variety of equipment from different man uf act tubers, all 
with different user interface standards. 

Equipment training onen includes no more lluin one or 
two hours of instruction at monitor installation time. The 
turnovc^r of the nursing staff may be very high, Bt^cause 
the workload is heavy, there is no timt* to read extensive 
operating manuals, instruction cards, or helii textB. Be- 
cause of eccmomic pressures on the health care system 
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and ciinical personnel shortages, espeeialiy in nursing, 
less tinie is available for in-service training. 

AH of this suggests that inluitiveness and ease of use are 
Inndauiental requirements for the Component Monitoring 
System human interface. 

Design Objectives 

As the perfornumce and i-ompntaiional power of a patient 
monitor increase, ilio challenge is how to preserit and use 
the medical infonnalion provided by the monitor in an 
easy-to-interpret, simple, interactive way that will lead to 
more eftlcient palienl care delivery. It Ls possible to con- 
trol a nionitur with two buttons and a lot of key pushing 
and watching. It is also possible to have 100 butlons or 
more for the same job and assign a distinct function to 
each button. An optimimi is somewhere in between. 

The main goal was to design a consistent control slnic- 
ture for all applications in I he monitor and across all 
present and future nUMttbers of the Component Mnniloring 
System family. Working towartls a simple model in die 
user's mind was considered more important than reducing 
the mmiber (5f ifeystrr>kes required ta acx'ess a given I'unc- 
tion to an absolute minimum. Having fonned a mf)del of 
how the system operates, the user can extrapolate how a 
particular fimction might work. If the system is consis- 
tent, the users [)rediclion will work, the system will be 
perceived }is easy to usi\ and user accei>lance itnd salis- 
faction will increase. The control struct uj*e needs to )je 
self-explanatoi^ to the no\ice user and allow fast access 
U) the cxperienc(Mi user Access to critical functions re- 
Liuirini^ inmuKliate action (like silencing an alann or freez- 
ing the screen) shunlrl be simple and fast and slumld not 
inleiTirp! the usc^rs activity in a given operating window. 

Minimizing operating complexity by reducing tiie nmnb<*r 
of nested operating levels and thus ehminaling the nee*! 
for ''navigation aids" htis been a mi\ior quimtitative goal. 
Each Component Monitoring System function is accessible 
within tliree operating levels, reinforcing [he same act ess 
to id I functions, I'here is a home key, labeled Standard Dis- 
play, whi<^h always brit^gs the user back to the stmvdard 
resting display. Because monitoring functions var>" In tluit^ 
complexity, the hujviaji interface design inv|jleinents simple 
things in m\ easy way while making complex Sasks possi- 
ble. 

Elements of the Human Interface 

The main elements of the Component Monitoring System 
human interface can be spen in Fig. 6 on page 12* All 
user interaction and data \isua I ligation take place Uirfingh, 
a human mterfat*' unit cnnsisling of a U-inch hi^h-resolu- 
lion display ( monochrome or color) and a keypad inte- 
gratetl in the screen l)ezel. t)ptionally, a remote kt^ypail 
can be attached to the Component Monitoring System 
through the standard HP-HII. interface. The remote key- 
l>ad duplicates all of the keys on the screen bezel and 
has an additional alphmmmeric^ entiy capability. The 
screen bezel also contains the soimd generator for the 
alami interface and the visual alann indicators, which are 
color-coded alarm lamiis (red, yellow, grtM?n). The controls 
and lights on each patietn parameter ttiodule are inte- 
grated into the overall operating concept. Each 



single- width ]:)arameter module has one or two keys, Une 
key is always a setu]) button, which allows diiecl access 
to the setup menu for tliat parameter modide. The other 
key is optional and allows quick operation of functions, 
such as zeroing a trai^sducer, stalling a cardiac output 
measurement, or calib rating the CO^ analyzer. 

Most operations are controlled by a mix of twelve hard- 
keys and seven so ft keys. A group of arrow keys on the 
right side of the kt^ypiad (up, down, left, right, confirm) 
support the pointing and select functions of the user in- 
terlace. 

Hifsim and Its Benefits 

Tiie control stnicture and the screen layout were exposed 
to nurses^ physicians, and anesihesiologLsts in the eaiiy 
stage of the design f>iocess. This vvjis possible througti 
tlie use of a simulation tool. 

At die time the human interface design started, very few 
sinmlulioji tools weie available, and in most cases they 
didn't match tlie designers' requirements- We chcjse to 
develop our own simulation tool, called Hifsim. This took 
four engineer-months. Ilifsim nins on an IIP 1H)()0 Series 
'Ml ^workstation under the IIP -CX operating system. 

The intended use of the Hifsim tool for usability tests 
made it mandaioiy to come up with a kt^ypad integrated 
Ittto tlie screen bezel to resemble as much as iiossllxle tJie 
way a nurse would interact with the monitor. Similai^ pix- 
el resolution and useful screen size to that of the final 
monitor were mandatoiy. 

Special himhvare was developed for the simulator It t oii- 
sists of a metal cover over the workstation's UMncli dis- 
play, leaving an opening similar to the C'omponenI Moni- 
toring System's useful screen area .Aji MP-IL button box 
wkis rnodiiied as ;i keyi>ad rei)lacemen1 and Wcis inte- 
grated into the rover. The eh^tlronk s of the but tern tK>x 
were used t*i connect a set of hai-dkeys embedded into 
the screen bezel, forming a close aptircjximatioii of the 
Onal screen bezel layout (see Fig. 2). 

Hifsim has two main sections: the screen generator and 
the simulation section. Tlie screen generator is basically a 




Fig, 2. Tlu^ HiMri simulator Ihiniwan 
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compiler thai interprets the Hifeini screen definition lan- 
guage Mid converts it into commands for the HP Starbase 
graphics software. This language is adapted to lite charac- 
teristics of the planned Component Monitoring System 
display hardware in terms of resolution, character sizes, 
fonts, colors, and special graphic elements. 

The benefits of the screen generator are: 

• Ser\es as a screen design tool 

• Ensures consistency m screen design 

• Enabled early selection of the Component Monitoring 
System color scheme 

• Generates "screen cookbook" 

• Supports usabilit>' tests 

• Aids in software implementation 

• Supports trade shows, demonstrations, and traiiting. 
Both sections of Hifsini are data driven. This means that 
tlie screen and operating dependencies are described m 
rUes, Everv' change in the screen content or operatit^g 
sequence is in^plemcnted by editing these files while Hif- 
sim is running. This supports the idea of interactive 
scr^n design and makes Htfsini a true screen design 
tool 

The monochrome version supports two intensities of 
green, l^p to eight colors can be used in the color version 
of Tlifsini. Bach color can appear with lull or half intensi- 
ty. Again, similaritj^ to the final display haidware attri- 
butes was mandatorv^ for the simulator, and the color 
map tjf Ifie workstation made it possible to generate any 
tiosired color. This allowed vjs to come up with a good 
definition of the Component Monitoring System color 
scheme under the restriction of tlie available hardware 
very eaj-ly in the huitian interface design process. 

Building a screen means specifying I he screen objects 
aiong with their attributes in terms of coloi; size, posi- 
tion, line style, and so on. Tht^ aliilily to define wavcfonn 
objects in temis of wave ajnplitudef trace lengtli. posilidit, 
and color was essential for tiie projier tjesigii of tJie reab 
time wnvelonu display. Tlie scrcpii definition language 
supi)(>rt.s j>rimitives for texl, wavefbrni*^. r(MiartgI(^s, size 
bars, value and alarm bars, lines, and polygons. 

Ilifsim made it pfjssilile for tlie human inlc^rface tie sign 
leant to visualize and distribute the screen design in the 
**screen cookbook"*, wliicli is a collection of about 200 
screen harder ipies bundled lofieUu-r to illustrate tiie Com- 
ponenl Monitoring HysKnu Ininian intertace design, Ttie 
cookbook was an essential element in the himian inter- 
face design process, U was used to get clinic:al user and 
HP management leedhack and approval very early in the 
design process. 

The effort spent in huilding Ilifsim was retiaid during the 
implenK^ntation of tiie human interface software. All 
screen definition details were used in the acttiai software 
miplementalion with virtually no <'hanges. The iniplemen- 
tatioi^ of the interface s I ask windtjw conuuiind laji^nage^ 
resembles the primitives ttsed in the Hifsini screen defini- 
tion language. 

The basic functionality of the Componcm Monitoring Sys- 
tem was developed jointly with tlie HP WaJtham Division 
in tlie USA, and Hifsim was used there as well for 
screen designs and simnlatioiv in iJiiiallel with the R&Il 



effort at the Bdblingen Medical I>hTsioa This helped 
achieve inherent coi^isjency. Because the same tool was 
used to getterate aU of the Componeni Monitoring System 
screens, the s<rreens' Sook and feel are consistent across 
all Component Monitoring System fiinctions. 

Hifeim was used widely in exposing the human interface 
design during show*s, demons! rat ion sessions, and market- 
ing training at a time when no finalized Component Moni- 
toring System hardware or software was available. This 
allowed the design team to get very* eariy feedback on its 
user interface design. 

Usability Testing 

Hifsim was a prerequisite for being able to set up the 
Component Monitoring System usability testis. The pur- 
pose of the usability tests was to discover which features 
of the human interface design were effective and which 
needed to be improved, and lo do this testing early in the 
design process where changes coukl slili be matle in I he 
hotnan interface design. 

An extensive usability test session was organized in the 
Boston area by an independent research instil ure tliat 
specializes in luinian interface studies and human factors 
reseaitii, Our objective was to t^rmducf an independent 
evaluation of the monitors user interface, basically the 
control structure and the screen layout. The test was con- 
ducted on a sample of 13 nurses and anesthesiologists 
who were asl<ed to perfonn tyijical |>atient monitoring 
tiisks. A second objective was to assess tlie value of us- 
ability tests as an aid to the design process of a moiiitors 
user interface. 

A game t>laii was worked out that included a list of 30 
different scenarios commonly pcrfonried by llie clinical 
pei>;onnel in o|HMatiiig rooms and iIh' ICHs. The lest ses- 
sions were conducted by a moderattjr wlio llrst read the 
task scenario iuid then tisked the test stihjecls In perfonn 
it. All sessions were videotaped ami mentbers of the 
Componenl Monitoring System R&D and marketing teams 
watciied iheiri in a sepmate room. This way iht* design 
engineri's got tlrstJiand insights inlo user reactions to I he 
human interface. 

Before each session the moderaior gave a very brief ex- 
planation about how the monitor works. This demonstra- 
tion was kcfjl to a minimum to test how c*asy it would be 
for a nurse to ojjerate the monitor wiih ahnosl no i)re- 
vious training. Tlie test subjects were asked before Uie 
test what furuHonality they expected b> activate with 
each li^udkey. In this way we got more feedljurk on how 
intuitive the t'omponent Monitoring System keypad Jabeb 
ing was. 

At the end of each session the test subjects were asked 
to prtlend that they had to train the moderaior to do a 
simple procedure, such as changing* th(» leads on the ECG 
or adjusting I he t^reasure altinii hmils. The t'^^ti^ose was 
to se** if they eonid ret all the |>ro( t*dure diey had jier- 
ft>nned about ati hour ago. This was a measure of iiow 
well they had learned and liow well they understood the 
operating concept. 

TIic* general ass(*ssment was that the Component Monitor- 
injt( SystiMU user ititerface is sound, easy to leani, and 
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elTecllve to use. A significant niinibrr of rcroniiiicndaljons 
and problems worp found, riuiiiy of which had not bpon 
reportf^d in previous tests with clinical specialists ajid IIP 
6mploye€\s, For example, the monitor has a function that 
allows I he user to activate or suspend the monitor's 
alarming capability. This function was implemented in the 
prototype as a toggle key. To suspend alarms, the user 
had lo press a soft key lat>eled Suspend Alarms. The label 
then cbangetj to Activate Afarms and an ALARMS SUSPENDED 
message ap[jeared in liie uppiw' pan oi' the screen. The 
subjects frequently overlooked thc^ message. They were 
therefore confused to see the soft key label changing to 
Activate Alarms. They were not sun^ whether tlie alanns 
were on or off. Kven with extensive explanations, they 
had trouble understaiuiirig the fujiclionaUty of Iht^ toggle 
soft key. Because this is a critical function that involves 
l^atient safety, we separated ihis function into two sepa- 
rate soft keys. 

The recommendations from the usability tests were incor- 
porated in the hunum interface design and new^ tests were 
conducted. After these were successfully pai^sed, the hu- 
man interface EHS (external reference specification J was 
ilnalized. 

The usability tests wen^ an essential milestone in tbc^ hu- 
man interface design process. How^veft the tests <jnly 
evaluated the system's ease of learning and initial ease of 
use. They did not evaluate how users would feel about 
the monitor after they had used it on a daily basis. The 
basic difference Ls thai users w!io know the monitor don't 
read latiels anymore. They simply [jiish keys in a "pre- 
st ored'* sequence. This emphasizes the Impoitance of con- 
sistency in the Component Monitoring Systeni human in- 
terlace design, hi addition, these tests did not reOect. how 
tlie user would interact with the nionitc^r in a clinical 
en\iroiunent, iti critical situations where fast access to 
some basic functions is essential. Let's come back to the 
example of the susjiciMl/activatt^ alarm function, fm^illy 
implemented with two soft keys. AJter release of the Com- 
lionent Monitoring System, we found that users in the 
operating room require a one-push key to suspend or acti- 
vate the monitors alanns. This is the way they are used 
to operating other monitoring eqiiiptneru. In addition, hav- 
ing direct access to tlie alann suspt^ntl furiction helps the 
user whenever special procedures are done on the t>iitleni 
that require aUirm suspension. This led lo the decision to 
ad<i a hard key on the keypad for the suspend/activate 
alann function. 

The verification pnicess did not stop here. Tests in the 
clinical environmt^it were cotuiuctCHl in the I .S.A. and 
various European countries before release of the Compo- 
nent Monitoring System to assess hs usability and to test 
speciTic monitor functionality. With each CoinponeEVt Mon- 
itorii^g Systeni release, further tine tuning of ease-of-use 
aspects has been done, but tJie main operating concepts 
ha%e pro vet! sound. 

Designing for Ease of Use 

To i^nsure intuitiveness and ease of use. a number of de- 
sign decisions were made for the human interface of the 
Component Monitoiing System. Tliese are discussed in 
the following paragraphs. 



Intuitivt and Explicit Labeling. Tlie hiuiian interface always 
uses verb+noun combinations as soft key labels (Change 
teadt Adjust Alarms, Select Parameter). It always uses nouns or 
objects for fEUuiional entries on the keypad (Parameters, 
Pattent Data^ Monitoring Procedures J. 

In the past each front-panel control had one function, 
which needed a label ffir explanation. To keep the prod- 
uct's appearance uncon fusing, it was necessary to alr>bre- 
\1aie labels. This made ihvm hard to interpret imi\ to lo- 
cal iice. The function of a key is mucb clearer if both a 
verb and a noun are part of the lalieK Then the control 
clearly does "something to something". 

All fimc^tion keys act only as soft keys— -they don't have an 
addiiioniil meaning as a hjirdkey. There Is always only 
one function assigned to a given control There are nn 
bkiden htnciions and no automatic screen actions, which 
are perceived as imexpected, are not obvious to liie user, 
and require extra training effort. 

Task Window Appearance, All task windows or setup 
mcrms hav4^ ilu* same layout jind appe^tr in the same posi- 
tioi^ on tlie monitor's screen. All information needt^d lo 
perform a given task is inckKied in this window. The win- 
dow ht?ight Is a ftinction of the tunount of infonnaiion 
that has to be presented. However, the basic design goal 
was to keep these windows as small as possible to mini- 
mize t he amount of screen tliey cover. 

Screen Eye Movement. The most critical information, such 
as patien! akirms, is placed on the lop right side of the 
screen, tie cause the vital sign numerics are critical foi' 
the patient status assessment, they always appear on the 
right side of I he screen. Prompts and status messages are 
always shown in the top middle portion of the screen. 

Context Sensitive Help. Thx^ Component Monitoring Systeni 
help function is intended lo replace the traditional in- 
struction f*ard, l^pon request (pressing the Help hardkey) 
the system jjrovides one or two lines of infoniiation 
about the functionality of the cuiTently activated softkcy 
or chc)ice. hi the case of in u It isle j) procedmes a more 
detailed dcscrii>tiori of the procedure steps is shown as 
j>ennaneni lielp inside the tjperaling windows None of the 
help components bides the cinrently active task window. 

Consistency. This issue is critical for the ease of use of 
the monitor. The same functions are kept on equivalent 
keys across dilTerent operating windows (e.g., the Adjust 
Alarms function is ahvays the rightmost st:>ftkey in any 
parameter task window). The same wording is used for a 
function thai apjiears in several windows (e.g.. Change 
Scale is used as a so ft key label whenever a chiuige in a 
parameters amplitude is implemented). All soft key labels 
are printed with an initial itpperease character followed 
by low^ercase letters. Highlighting is always used to indi- 
cate that a given field is cun'ently acti\e. Blinking is al- 
ways used to indicate that an iilann condition is present. 
Operating the monitor from tlie screen bezel or tile re- 
mote keypad is the same. All bezel keys appear in the 
same layout on the remote keyj^ad. Rules and guidelines 
ensure that application software mothiles present task 
\\'indow^s in a consistent w^ay. This applies not only lo the 
nin-time task window^s but also to all [larameter configu- 
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ration windows. All have similar ^pearances and identi- 
cal controls. 

Color. Color is additional and redundant and nf?\'er used 
as the only coding scheme. Color is used basically to dif- 
ferentiaie reai-tinie waveforms displaycni in an o\"erlapping 
fashion. Pieces of information Ihai belong to one parame- 
ter source (such as the real-time waveform, numerics, and 
the trend wave) always have the same color. All opemting 
windows have the same color (cyan) and all softkey la- 
bels are white on cyan, .\larni severity is expressed in the 
colors of the alert messages. Life-tlireatening alarms are 
in red» caution or warning alarms are in yeliow, and inop- 
erative conditions ai'e shown as green messages. A red 
X-bell symbol is used throughout the system to indicate 
tliat alarms are turned off. 

Avoiding Operating Errors, All choices for a given function 
;irc always shuwiu There are no liidden choices. The sta- 
tus of a given setting Ls shown before a change Is initi- 
ated. Prompt uK^ssages and prompt sounds are used to 
infonu the user if an action cannot be executed properly. 
Actions like pressing Confinn or nnishing inulHstep proce- 
dures (e.g., zeroing a pressure line) always result in a 
prompt message and sound. 

Graphics. In addition to digital readouts, graphic elements 
are widely used. This Includes size bius for iunplitude 
acUusLnienLs aiul audible volume control and aliutu and 
value bars to indicate the current range of alarm limits. 

User Defaults and Configuration Sets. The basic design goal 
Ls Lfiai it be jjossible to tuni on Uie monitor, attacli the 
transducers ajtd electrodes to the patient, and start nioni- 
tcjring wilhoul any furtlier settings or a(tiustments. This 
means that the monitor will initiate at power-on with a 
set of user-definable settings. These user defaults can t>e 
specified at installaiion time and changed whenever re- 
quiiTd. They are stored m nonvolatile memory and read 
after monitor restart. This applies to every parameter 
module in the Con^ixment Monitoring System. 

In addition, a whole set oi' user settings related to one 
specific Component Monitoring System element, such as 
the display or the recorder conliguration, can be bundled 
tcjgetlier :ind accessed l>y a single ke^TJUsh. For example, 
all screen related attributes, such £ls wavefonn asslgn- 
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ment to display chai^nels, nuniber of waveforms, speed of 
waveforms, and overlapping formats, can he put together 
as one screen choice. Up lo three different screen 
choices can be stored in nonvolatile memory. This sup- 
ports applications in the operating room, where depend- 
ing on the course of surgery, specific screen layouts have 
to be accessible without complex interaction. 

Finally, the «!oncept of a configuration set supports the 
monitors ease of use and OexibiUty^ by customizing the 
parameter algorithm l>eha\ior atid the parameter settings 
according to the specific environment (operating room or 
ICIJ) or to the patient^s age (adult, pediatric, or tieonaie). 
ITie user can specify or change the monitor's behavior 
simply by selecting one of the four av^ailable coidlguration 
sets prestored in the monitor This again simplifies the 
monitor's setup in an enviroiuuent like the operating 
room, where patients of different ages undergo surgical 
inter\'entions. 

The Eesting Display 

The resting display is what the C omponent Monitoring 
System shows when no user interaction is taking place. 
Fig. 3 shows a typical resting display. 

Since the monitors main hmk is lo nteasure a patient^s 
vital si gas and give an alarm if a critical situation occurs, 
the top line is reserved for alarm information, h also con- 
tains the patient's name, the current date and time, and 
the basic configuration of the monitor — for example, a 
ciiLss ill cation of the pal lent arul the application area for 
wlildi tlie internal algorithms are optimized. 

The next line contains status and prompt messages in- 
fonning the user about events that are not as critical as 
alanns, but give LnfomiaHon ab<Hjt sucl) things as suc- 
cessfully tlnished reconhngs or pariuueter calibration pro- 
cedures. 

[)epending on thi^ Component Monitoring System configu- 
ration and tiie users choice, the resting display sliows 
four, six, or eight real-time waveforms of the measured 
parameters with the digital values derived from Ihe wave- 
funns displayed trcxt to t.liem. For better vertical wave- 
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form rcsoluLiorK ii[) i(j Uvn groups (if wav(^?^ am share 3 
larger sector on I he f?croeii. 1'hjs overlap] linj^ (jf wave- 
forms allows tlie user lo cunelate difftTcii! waveforms on 
fhE"^ time axis. 

Eadi waveform ehajinel can be iissigned a flifferent 
speerL TVvo presentiitioii modes of the wavefomis are 
possihle: either thi^ wavefonns are fixed or\ I he srnH^ii 
and old wavefonn samples aix^ erased hy die newest ^ or 
the wavefomis move aeross tlie sereeii wWh the iiew^est 
samples always next lo the distal values. 

The content of t^ach t*!iannel can be configured. Addition- 
ally, the user Iuls I ho rlH>iC'<" of three precontlgure^! 
screens lo makf^ it ijossibie to adapt (|uickly tti <'han^e.s 
of the patienfs c*>n<h1iniL 

Digital, Values 

The user has dennite oqiectatinns about where, when, 
and in wliat fonnat digital values should api>ear. The re- 
quirenients for the arrangement of the digital values were: 

» The values of a parameter plugged into a rack or tunied 
on should show up aulorualically. II Ls imaecepi;^ble lo 
have to position I he value of such a p^irameter manually- 
It must appear in the riglU position. 

• Tlie digital values niUJ^t be placed nex( b> I heir ( <irre- 
spending wavt^forni if possible. 

► As many values as possible have to be shown wilh laigc 
digits. On a full disjilay if is acceptable for I lie tt^ss i[iipor- 
ta.nt values to be shown with small ttigils* bul not on a 
display with just ti¥o measured pai^anielers. 

These reQUirements are met by an elaborate alg^orithm. Et 
Ls an iterative process that tries to find a plaee for all 
digitai values available in I he system. It llf^il jj laces all 
values next to their wavefomis with large fhgits. It tfien 
places all other values, atT-ording to a priojity ILst, ui the 
riglit column next to the wavefonu values. Temperature 
values are first assiguetJ large digits, 

Lf there are si ill tniassigned numerics left but nci more 
s}>aee available, the algfiriUini st^uls (tecreasing values in 
size, starting with those f>f lowest priority, anti repeats 
the process. As a last resori, teniperatm-e values are al- 
lowed to share the same place, altematnig at two-second 
intervals. 

Operating Concept 

The general operating stm^iure of the Coiuponetit Moni- 
toring System human interface is described by the state 
djagi"am shown in Fig. 4. 



Keypad. Alter the keys on the parameter modules, wliich 
are mainly used lo center Iht^ nieuus juirl atyusl jxirameter 
settings, tJie keypad uiidenieath iht* screen is the main 
tool for users to interact with the monitor. Fig, 5 shows 
this keyiJHfi. .^s mentioned al>ove. a handheld keypad for 
remote operalion has some additional fimctions available. 

The fit^t row {>f keys on the keypad t*oiLsists of seven 
furictioi; kf\vs. Th*nr functions are cletlned by the menus 
thai appear tin ttie screen. 

The next row of keys is used to enter sbc different cate- 
gories of monitor interaction- 

The loW'est row contains keys that immediatetv stai1 ac- 
tions that are frettucntly used in the hostjitafs daily rou- 
tine. The Standard Display key always returns <'ontrol to the 
resting display. 

The Sitence/Reset key is used to silence or reset alanns, 
The Suspend key is used U> susiK^nd or activate instnuuent 
alami capability. There are alaravindicating LEDs on the 
left and a diamond of four cui-sor keys and a Confirm key 
on the far right The last group fjf keys gels highlighted if 
they can be used. 

The Array of Choices. Tf one of the keys in the midfTle row 
IS |iresse<l, Ihe wsvv iiTMiiediattdy gets a display of all of 
the interactions (hat belong to the categrjiy' described on 
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the entry ke>^ (see Rg. 6). There are no hici<!en fiinrtions 
tha! the us^r might rememhcr but does not know where 
to look for. 

Behind somp of the entry keys there can be more than 
seven functions. Thus the user is shown an array of 
choices with op to four possible hnvH of soft keys. The 
nimibcr of entries depends on the categorj' and the con- 
figumtion of the Comix^nent Monitoring System. The ac- 
tive line is shown in full intensity. It can be moved up 
and dowTi either by repeatedly pne^jing the enlty key or 
Willi the cursor keys. 

The array of choices illustrates three important mecha- 
nisms that occur consistently throughout the operating 
concepts 

' Resources, such as the place occupied by the array of 
choices, are used accoixling fo the system configuration. 
' Selected itenxs are shown in I'uil intensity 
' Two methods are consistently allowed for selecting an 
item: either by repeatedly pressing rhe key that was used 
to enter the context, or by usin^ tJu* cursor keys. Usabil- 
ity testing has showi^ thai fliere are personal preferences 
for either method tJependiiig on the user's background. As 
a third method, touch would not clash with the operating 
structmes, although ir is not offered at this time. Inverse 
areas in half iiUensily could hv activaietl by touch. 
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Fig. 7. Tht* generic Iwyoui of a task wliuiiiw. 

Task Windows. The array of choices is an hitennediai^ 
siej) m eniering the next operating level, the task window. 
Fig, 7 sJiows tJie generic layout of a task window. The 
possii)le functions ;iie labeled wi(h iuvei'se sf) ft keys, 
which do not change in this context. The ciuTcnlly active 
function is highlighted and lhik:ed to the interactive area 
abovet which can contain items to be selected or special 
contents needed for tliis specific softkey. 
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The status area undemeath the title contains all status 
infomialion atKjul Itie cun'ent task — including a real-time 
wavefbmi it available — to make sure tliat Oie ust^r floes 
not have to select a function just to get more informa- 
tion. The user only needs to press a softkey if something 
is to be changed. 

If required, tiie rightmost softkey caji be used to jump 
back and forth to a subsequent tiisk window. As an exam- 
ple» Fig. 8 shows an overview of the operating levels for 
three parameter setups. 

Human Interface Software Architecture 

The Innnan interface software is embedded in the overall 
Comijoiienl Monitoring System software aichitecture. It is 
one of the large data sinks lliai make iutt^nsive use of the 
communication model wil^li Its message passing concept. 
The weli-strortured information provided, for exan\ple, by 
the standard parameter interface (see art.iclej page 19) 
makes it possible to add new parameters with virtually no 
changes to tht^ human interface software. It also allows 
resources to be used ver^^ effectively by alloialing 
memory depending on the number of messages to be pro- 
cessed. 

Fig, 9 shows the layered structure of the human interface 
software module. Each parameter module, even a new 
one, broadcasts Its statulard parmneter interlact^ messages 
and is aulomaticaliy recognized by the screen configura- 
tion software. To get a task window, ^my application soft- 
ware module either applies directly to the task window 
arbiter or specifies an enliy^ in the turay of choices. If 
selected, the aiTay of choices manager iirnmges a dynam- 
ic link between the parameter module and the task win- 
dow arbiter. 

Any application software module can present infunnation 
in a task window^ by using a conunand laitguage that sup- 



ports the specific elements of the human interface. This 
is an effective way to achieve the required consistency 
across all task window^s. The content of the task wuidows 
is determined by the application, but human interface 
related definitions are coded in the command language. 
Thus, most changes affecting Mie human interface design 
have to be done in the human interface software only 

A powerful standartiized keyhandlcr Ijuilds the ijiterface 
between the application software tmd the task window 
command language. The command language hides the 
pixel coordinates of the (iisplay conl roller from the apph- 
cation sohware. Thus, the application software tloes not 
have to be changed in case the display technology 
changes, tor exmnple to LCD. The coordinate system of 
the task window <::onmiaiid language is the same as w^as 
used tJuring the human interface screen simulation. 

There iire asynchronous FlFCl buffei^ in the paih betw^een 
the task window conmiands and tlie connected h aid ware 
devices, ntainly the dtsplay controller. A special hand- 
sliake niecli^uiism based on the monitoilng of token mes- 
sages guartmtees thai the FIFOs cannot be flooded in 
peak silualions. 

By setting \ip ilie huttmn interface module two or more 
times in the monitor ctjntlguralion laL>le (see article, page 
13) and plugging n\ore display crjiit roller cards into the 
computer module, several independent displays can he 
connected to one (Component Monitoring System. 
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Globalization Tools and Processes in 
the HP Component Monitoring System 

Software design and localization are decoupled. All languages are treated 
in the same way. A database contains the text strings for all languages, 
and automated tools aid the translator 

by Gerhard Ti\ig 



ThD IIP Componem Monitoring System is an intemational 
product designed For a world\^1tle market. Among the 
RHinlremenLs For Itie pn>durt were introduetion of local- 
izf'd versions sinnilrane<nisly with the shipment of the 
standard product, lull Mian language support, and low 
incremental effort for localization in any new language. 

At fii^t release, the product was localized in the following 
lan^iagps: English, Germait, French. Dutch, Bwetlish, Ital- 
ian, and Spanish. A Kai\ji/Kana t>n>totyt>e version was 
available as well. Tlie cuiTcni release is also localized m 
Danish, traditional Chinese, and siniplifjed Chinese. 

Local izatia II Goals 

To fill I ill I he reiiuire agents, a number of ^oali> were set 
forU^ vety rleai^ly in the design pha,se ol' \he Coint>onent 
Monitoring System softwaie. The ni^jt>r goals werv the 
decent raiiKat ion of localization effoits, the auU>inatJon of 
tire locatization process, and the standardization of inter- 
fares, 

Oeceittraiization. Decoupling the software design and im- 
piementation process (R&D responsihility) IVoni the local- 
ization process (technical market iiig respcaisibility) inaltes 
i\ possible to produce a local is'-tHl Comfvonent Monitoring 
System without intt^mipting ifie software engineers work- 
ing on their stjftwiue modules. The coorflinaiion and tim- 
ing of the translations are not directly coupled with the 
software development process. 

Automation. Automated processes to generate localizetl 
(■ninpf>ncnt Moniioring Sysiem software allow efficient 
generation of Itjcahzed ver^^ions wlu^ never tliey are need- 
ed, especial iy in prerelease phases (regulatory approval, 
clinical trials, demonstrations, etc.). The automated pro- 
cesses transform all Component Moniioring System text 
sitings front ijlain English to the equivalent liexadecimal 
character representation. Auloniatic fomiat rliecking is 
pari of this process. Translation of all text strings of a 
Component Monitoring System softwai\^ releiise in a 
single pass improvt^s the consistency of the trkuislated 
text: — similar (enns are translated rlie same way in vari- 
ous places. The same tnmslator is responsible lor t(?xt 
strings and for the operating Guide translation. 

Standardization, A we U-struc tared native language support 
(NLS) < la E abase is needed. The generation proc€*ss for 
localizeti software sjiuI flic Irmislation process are the 



clients of this database. The NLS database is pari of the 
Component Monitoring S>^lem software maintenance sys- 
tem. 

Shuple and standardized imeifaces between the compo 
nents of the localizaiion process are necessary. This in- 
cludes conunon 11 le formats for the NLS database, com- 
mon tools for accessing and handling text strings, and 
conmion tools aitd processes to translate and generate 
localized solYware. 

Design Decisions 

Specific design decisions had to be made to achieve these 
goals. Among these aie: 

* The HP stand^wd RontanS character set is supported. This 
allows localization of ni> to 14 Western European lan- 
guages with one RomanH character generator, which is 
located on the display controller function card. This con- 
siderably simplifies the handling of European language 
options. 

* All character codes arc two-h>yie ccKies. Thus all text 
strings use two-byte character codes. This allo^^ s support 
of Asian languages as well as all European languages in a 
consistent way. For liomanS characiers, the upper (un- 
used ) byte is cleareiL 

* A given text siring has a fixed field length across all lan- 
guages. Thus the field length of a given text string is not 
language dependent and the access of a software n\odule 
to its text strings is language independent, hi addition, all 
text strings are terminated with an end-of-stiing chaiac- 
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ten There is no language dependency in the way strings 
are handle tl in tUffenml languages. 

• Tex I strings ^ire sep£ualtxl from module code. All soft- 
ware modules are lajiguage independent. Inside eat^h soft- 
ware module^ all text strings are located in TEXT directo- 
ries, thus being separated from the code (PROG) directory. 
Changing ?exi stringy from one language to another does 
not aJTert the ( oniponenl Moniloring System codc^ No 
recDrn[>ilaiion of tJie software is necessary when a new 
localiised Component Monitoring System version is pro- 
duced. 

• Stand^u-d HV16 codes for all /\sian hmguages are sup- 
ported. This allows the Component Monitoring System to 
handle all A,sian languages identically and supports the 
connection of Asian printers m^ well. For each i\sian lan- 
guage, a specific Asian EPROM card with the complete 
font .set h suppt.^rted. 

• The standard t:haj*acter cell suppuits all Asian language 
fotvts. The standartl chai'acter cell Ls Hi pixels wide hy 2(J 
pixeb higfi. Tlie Asian fonts (KanjiTvana, Cliinese) are 
handled as right -justilied IB-byi 6-pixel eharact^ers (see 

ng. 1). 

A pixel is 0.219 rnm wide by 0.352 mm high, gi\1ng an 
aspect ratio of 1.5- An Asian character should have a 
square appearance, so the display cotUruUer fimiwaie 
doubles eaeli pixel in the x dirnension. This metms that a 
Kai\ji ehamcter lakes twice as much space in a horizontal 
stilng as a RontanS character. Since each Kai\ii character 
occupies two nonnal character cells, all Asitm strings are 
limited to half the length t>f RomauS charact*^r strings. 
The Asian translation tool takers this restriction into con- 
sideration. Fig. 2 shows die tiadition^iJ Chinese translation 
of a typical Component Monitoring System task window. 

The NLS Database 

The NTjS database tontains ail strings that mv visible to 
the Component Monitoring System user. Tt\ey show up 
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Fig. 3. NILS diiiatiasp strvicture. 

mainly on the screetL hut n\ay also be present on the 
kt\>pafl and the patiejil parametcT module panels. 

The database is organized under tlie IH*-L/X file system as 
liierarf hical fik' directories (see Fig. 3)/rhe database is an 
integral part of the Comt>onent Monitoring System tiocu- 
mentation and is maintained witli the HP-UX res tnility 

Below the main emry, a distinct entry called a LAN(](uage) 
tree is provided for each language. Tliere is a basic direc- 
tory wliert* iill localizable strings are stored in plain En- 
glish. Tins is \\w RAW <hrertory Its structure is ideulical 
to all of tlie lAMG trees but it is not knowu to tiie transla- 
tion tool and to the text GompUer, Whenever text strings 
are added, deleted, or changed, this threctmy must l>e 
updated. 

The LANG trees are organijsed as a collection of valid NLS 
revisions, stich as ENG/ENG6.1 or GER/GER6.2, Tlie Ki^glish 
revision is the stalling point tor all fuHiier tianslat ion 
activities. All LANG trees have an identical structure atid 
iLU*e conniosed of a collection of NLS entries such as ECG, 
PRESS, and so on. Each softwme [nodule has one NLS 
erUr> in the tiatabase. Keeping all text strings of one soft- 
ware module together eases and improves the translation 
of the text *ilrings of that module. 

Each NLS database entry contains a set of NIJS files that 
incorporate the text strings. A standaicJ file format is es- 
tablished for ^ill NLS files (see Fig. 4a). It is processed by 
the NLS tools and recognized by tlie ti-anslarion took NLS 
files contain titJe, header, context, and text sections. Ttie 
title section corUains the pathnaniCj language, and revi- 
sion of the NIi:J file. Tlie headiT section is a list of format 
specifications, such as sz for string size or Jc for initial 
caps, which are read by the hexpander tool (see below). 
In the context section, ad%asory infonnarion is given to 
the traiislator to make translation of that NLS file easier 
It is read only l>y tJie translation tool The text sectiort is 
t he l)ody of the Nli^ file. It contains a sequence of items, 
each item identified by a test code and a text string. 



Fig. 2. TraLlltiunal ChiniLse < laiishition of rli«.* pressure oalitjratioii 
ULsk \t1nftow. 
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m^ Tools 

The hexpander and the s>Titax checker aro used to gener- 
ate and ciieck the hexadecimal rliaracter strings in the 
Ef^G director>^. The text compiler interfaces die NIS data- 
base to the C source code- Fig. 5 shows how tlie NIS 
tools interact with the Nli> database. 

The hexpander takes the plain English test finom the RAW 

direct Dr>' and generates the hexadecimal character strings 
in ihe ENG dkecion- according lo the forma! specifications 
(see Fig. 4b), A ytility called make.hexpand auifnnates the 
prorc^ss of generating and chec^king tiie syntax of tiie hex- 
panded ENG strings. 

The syntax checker reads the hexpatided files and Hags 
syntactically incorrect strings (eg,, loo long). A similar 
checker is incorporated into the trai^lation tool to check 
Ihe hexpanded ENG NLS file before translaUon takes 
place. 

The text compiler links the C source code with the NLS 
database, which contains text strings collected in files. 
References to these files niclude the language, rhe module 
Quiry (such as ECG or HEART), and the specific tile {contain- 
ing a given class of text strings (such as SK_U\BEL or 
ALERT). Fig. 4 shows im example of tlie ECG/SX_LABEL text 
file 

In the TEXT directory, the programmer specifies a source 
file (of class txt) which coulaitvs the references to the 
NLS fiJes, such as !ECG/SK_LABEL 2.1 The m file is identical 
to the .c file except that it has the NLS file references, 
(preceded by the escape character f), which must be 
resolved before the file can be conipiled (using make). The 
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paranieier labels leg,, ^RESS) are written with inilial capllais. 
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Fig. 5. NLS tools. 
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^iH- fii n L f ) f L 1 le I k « ? X \nu I c 1 t'f I tl 1 ( ' 1 [ I T he ENG direct 013 . 



text compiler resolves these referenres. It reads tlie liex- 
pantied NLS file (Fig. 4b h extracts the hexadecimal eqiuv- 
alents of the rellereneed text strings, and replaces the 
NLS fde references m Uve -txt file with these strings. The 
ouffiut is the (' source file (f>f class x). 

ThiiSt the text compiler is simply a preprocessor that 
takes care of the tex! strings. The programmer of Ihe 
software module does not have to ki>ow wliiil iiexadeci- 
tmii stj-ings are ultimately loaded itito the .c file. Thi^ is 
language dependent and does not affect tlie c code. 

To aulf)mate this i>rocess, the make.lang tJtiiity was estate 
lishc-d. 'fins utility is a scriiif tiuU exeruifes the text ci>ni- 
pil(T for evety software nujdule dial cortfaitis referenct^s 
to kicaibable tt!Xt strings. The text complier rt^solves 
these references by insert irtg in the intUcated places in 
the txt nies the hexaderirnai equivalents of tlie text 
sihngs. Tlie oulput x file is then compiled by die make 
til i lily in fht^ usual way. An example of calling tJie 
make Jang utility is: 
makejsng "NLSREV=7,2" "tAWCi=ENS" 

LDcaJizatioii Process 

The proc ess csiablislu'd to implement the kjcalJKation 
activities is showti in Fig. i'h 

R^n is res[>onsihle fur the generation and nminlenanee of 
die NLS daial>ase and the RAW and ENG language trees. 
The checked-in ENG revision is the starting point for all 
translations. Titis ENG tiee is pnmded to the technical 
marketing gjoui) t*jgetlier witli a del I a list ctjntaining all 
changes from dve i>revioiLs ENG revisitin. This gt 011(3 is 
respt^nsihle for driving iuid c oordinating die traiislalion 
[process. When this process is complete, the transiated 
tANG tree is loatied hat^k into the NLH dalahase. Auto- 
mated utilities sLich as make cms are used in R&n to gen- 
erate Ihe localized i'omponent Moniloring Syslem soft- 
ware, R^^f) is responsihle for providing tlie EPROM caiiis 
with the l(H'aliKt^<l software. A quaUty jissui-ance cycle 
similar lo thai for Ihe ENG vemitiji is then stalled for each 
Jocalizc{l vi-rsion. Pan of the QA process is a consistency 
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Fig, 6, Tbc^ EocalizatJon process. 

and wording chock of the localized software. The lan- 
guage vetificaLion is scheduled and coordinated by techni- 
cal marketing. Tlie sanie translator who did the Compo- 
nent Monitoring System translations is assigneti to 
language verification of iiie Component Monitoring Sys- 
tem product. 

IVanslation Tool 

The localization goals could noi have been achieved with- 
out a powerful and versatile translation tool. Because 
notiiing was available off the shelf, we had to write our 
own. The tool is personal-romp uler-basedj tlius allowing 
translations of the Component Monitoring System Icxl 
strings in each local HP oflice. The tool support.s Ui-bil 
character codes. It handles the standard Rom an 8 charac- 



ter set and allows printing of the translated strings on a 
IIP L.aserJet printer. 

The tool is designed to facilitate translations of large 
Quantities of text. The tool reads the English source files 
and presents the translator with tlie destinat ion fields for 
the translated strings, which are then written to the re- 
spective LANG tree. 

Translation is possible for a complete LANG entry, for spe- 
cific NLS entries (e.g., all strings of the E('G software 
module), or for specific text files inside one NLS entry. 
Printouts can be made from each of these translation 
levels. The user interface is soft key driven. 

Presently, this tool is used throughout the HP Medical 
Products Group and is supported by the CAD/producti\ity 
group at the Boblingen Medical Division. It allow^s effi- 
cient translations with a clear, standard interface to the 
NLS database and the Component Monitoring System soft- 
ware development group. Its major benefit and achieve- 
ment is the separation of translation activities from the 
software development efforts. 

Acknowledgm e n ts 

Many thanks to LJlrich Muskatiewitz who wroie the. trans- 
lation tool and extended it to cover Asian languages, to 
Satoshi Yamada of Yokogawa-IIcwlett-Packard for his ex- 
tensive suppori in implenicnting Asian languages, and to 
Harald Greiner wluj was responsible for implementing the 
Asian Ibnls and dissociated control meclumisuLs ui the 
display controller fi mi ware. Th^uiks also to Martin Kat- 
schner whose contimious support of the tnuislation tool 
and translation activities allowed us to localize the Com- 
ponent Monitorit)g System product in seven languages on 
time for the llrsi release. 



The Physiological Calculation 
Application in the HP Component 
Monitoring System 

This application converts raw real-time data into derived values the 
clinician can use to assess the patient's hemodynamic, oxygenation, and 
ventilatory condition. 

by Steven J. Weisner aiid Paul Johnson 



The HP Component Monitoring System bedside monitor 
provides the clinician with a variety of vital-sign paranie- 
lers sudi as heart rate and respiration rate. These raw 



values and the associated alarms wrc very important in 
monitoring Ihe patient. However, the liunian body is not a 
collection of independent physiological systems. Rallier, 
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all rn^or body systen:^ interact in a variety of ways, 
majny of which can be calculatt'd by combining the raw 
parameter %^iies into meaningfijl indicators. 

Physiological calculations are used routinely by many 
hospitals as part of their normal assessment and rec- 
ord-keeping process. Calculations provide a way of quick- 
b* reducing a large number of variables into a single num- 
ber that represents a comprehensive physiological 
function. For example, to measure the load appEed to the 
left ventricular heart muscle during the period of the 
heartbeat when the blood is ejected from the heart into 
the rest of the body (ventricular flection), a variable 
called systemic \^ascular resistance (SVR) can be circu- 
lated from measurements of the mean arterial blood pres- 
sure (ABPm), central venous pressure (CVP), and cardiac 
output (CO).^ 

Studies have shown that calculated values such as pulmo- 
nary vascular resistance (PVRJ and left aiid right cardiac 
work fLCW/RCUO are good pretlictors of m;^or malfunc- 
tions or niortality in intensive care patients.- Other stu- 
dies have validated the efTicienry of usini^ calcuialions 
such as stroke index (SI) and left and right ventricular 
stroke work (LVSW/RVSW) for preoperative assessment of 
unacceptable risks for m^or surgery.^ 

The Typical Calculation 

PoiseuiUes law ciesc:ribes the laminar, constant flow of 
Nevitonian liquids through rigid cyliiicirical tubes. Accord- 
ing to tills law. The mtio of pressure drop to the rate of 
Oow is a function of ail of the I'orces that retard this flow 
(i.e.j radius, len^h, and viscosity). Blood does behave as 
a Newtonian fluid in blood vessels tiiat are greater than 
0,5 nmi in diameter. Blood flow ihrough these vessels is 
generally laminar, all hough die iuteriaJ tree exhibits more 
pulsatile behavior Althougli hk)od vessel radii do vary 
slightly be<!ause of the applied pressure of the blood, Poi- 
seuille's law can be used to calciilate a first-order approx- 
imation of resistance by applying Ohms law for elecLrical 
circuits. 

Jiist as resistance in a circuit is equal to the voltage dif- 
ference divided by the current flow; vtiscular resistance 
(R) can be approximated by dividing the pressure differ- 
ence between the inlet of the vasc^ular bed (PI) and the 
outlet of tlie bed (P2) by the blood flow ((j). 

R = (PI - F2)/Q. 

In medical terms, we measure the difference between the 
mean arterial (ABPm) and venous (CVP) pressures and 
divide by the cardiac output (CO). The resultant value is 
converted from units of mniBg/l to units of dyne-s/cm^ by 
multiplying times 79,97. This value is called systemic vas- 
cular resistance (SVKJ. 

SVR = 79.97(ABPm - CVP)/CO. 

With this value, the clinician can get a measure of the 
consfriclion of l>lood vessels (vasoconstriction) or expan- 
sion of the blood vessels (vasodilation). Changes in SVR 
are related to other cardiac failtires such as hypovolemic 
shock, left ventricular failure, c^u-diogenic shock, and hy- 
poxeuiia."* 



Other calculations used to assess the state of the cardio- 

\'ascular system are shown in Rg. 1. 

The two pr^sure measuremenls .^BP and CVP are ac- 
quired through invasive pressure catheters jrttached to the 
patient and monitored throu^ the Component Monitoring 
System parameter modules. The cardiac output panmieter 
is obtained through a CO parameTer module and mea- 
sured using a monitoring procedure, which requires the 
clinician to interact with the Component Monitoring Sys- 
tem. The acquisition of the output %'alue (SVR in this 
case) and the presentation of the calculations to the clini- 
cian are described in the following sections. 

Data Management Package 

Tlie calculations package m tlie Component Monitoring 
System Is a subset of a more general data management 
package. This package consists of seven Component Mon- 
itoring System appUcation software modules, as shown in 
Fig. 2, The data acquisition tnoduh^ acquires and averages 
mw parameter data (e.g., heart rate) over a one-minute 
period. This raw data is available as a broadcast n\essage 
on the Component Monitoring System*s internal message 
passing bus. The one-nil n lit e-ave rage data is stored in a 
buffered fiAM database. The database module provides 24 
hours of data storage for 16 continuously monitored pa- 



Body Surface Area; IBaycJ's Formula) 

SSA = (3.207 X m ':<"^^^^- o-^^ee . \nm\ ^ ^j^2 j 

Cardi^e Index : 

CI ^ CO BSA 
Stroke Volutne ; 

sv = CD >< wwm 

Stroke \r\6et : 

Bl = £V BSA 
Sysieinic Vascular Resislance : 

SVR = 79 96 X (ABPm - CVP) CO 
Systemio Vascular Resistance Index: 

SVRl = SVR « BSA 
Pulmonary Vascular Resistance ; 

PVR = 7&.96 X (PAPm - PAWP)CO 
Pulmonary Vascular Resistance Incte;^ ; 

PVR1 = PVR X BSA 
Left Cardiac Vifork : 

LCW= CO X ABPm^ (J.0138 
Left Cardiac Work Index : 

LCWI = lew BSA 
Left Ventricular Stroke Work : 

LVSW = SV X ABPm x 0.0136 
Left Ventrioular Siroke Work Index ; 

LVSWI = LVSW BSA 
Right Cardjac Work - 

RCW = CO X PAPm X 0.013« 
Right Cardiac Work Index : 

RCWI " RCW BSA 
Right Ventricular Siroke Work : 

RVSW = SV X PAPm x un% 
Right Ventricular Siroke Work Index ; 

RVSWf = RVSW BSA 

WT - Body Weight m g 

HT - Body Heighl in cm 

HR - Heart Rate in beats min 

CO ~ Cardiac Outpul in I mIn 

ABPm - Arterial Blood Pressure Mean In mmHg 

CVP - Central Venous Pressure «n mmHg 

PAPm - Pulmor^ary Arierial Pressure Meart In mmHg 

PAWP - Pulmonary Artarial Wedge Pressure in mmHg 



Fig. 1. H^itwdynnnijc caJcuJations performed by the caltuJatioti 
evaliiator rnodulp of the Component Monitoring SysUrii data mmi- 
agofiient software patika^lt;. 



iinils = m^ 
Units = J miiv-m' 
Units = ml 
Units = ml.m^ 
tirtila = dynes'sec'tm^ 
Unll^ - dynes-sec-m^cr 
Units = dynes-^ecicm^ 
Units = dyneS' 
Units = kg-m 
Units = kg-m m'' 
Units = g-m 
Units = g-m m^ 
Units = kg-m 
Units = kg-m'm^ 
Units = g-iTi 
Units = g-m m' 
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Fig. 2. DnUi niaiuigenit'jii diiia 
now tliagF*'in^. 1 he (tala niaiiagp- 
merU packiigti consist s tjf severi 
appHcatJon software niodulos. 



rameters with one-minule resolulion. Paranietprs that are 
measured intennitlently or as part of a procedure, such 
as noninvasive blood pressure or cardiae output, are re- 
ferred to ^is aperiodic parameters. Thie database nwdule 
allows storage of 36 aperiodic parkin leters, each contain- 
ing up to 9fi inejisurement points. All retrieval of the data 
is mediated by retiuc^t messages antl return-data mes- 
sages sent acToss tlie message passing t>Lis. 

The acquired data can be presented in four forms. A talj- 
ular data display (UPC_TABULAR) presents 1-3 rows of pa- 
rameters in eiglil tnluiuns of time. A graphic (rends dis- 
play (UPC_TRENDS) sJiowhi up to nine pararueter-s in ^rapbie 
fbnn un three separate axes, (^attndations are done by 
two modules: ibe calculation evaluator (CAtC), wbicb per- 
forms tbe calculations, and the presentation module 
(UPC_CAtC), which provides the user inteiTiction with he- 
modynamic, oxygenation, and ventiJation calculations. The 
cliniciaji can also review the calculated data as a function 
of time in a tabular fonnaL 

Finally, there is a report package, which provides printed 
copies of any of tbe tabular, trends, or calculation dis- 
plays. This repoil is jireformatted imd can he [ninted lo- 
cally at the bedside or tTemqtely on a central prlnler. 

Calculation Evaluator 

The calculation evaluator module (CALC) is a collection of 
services associated with jihysiological calculations. These 
services are invoked liy means of messages sent to tlie 
CALC module. Topically, applications such as UPC_CALC in- 
voke the fmictions of acquiring the appropriate reference 
time and input parameli^rs for the calculation and then 
calculating the output values- 

In addition, the CALC module provides a separate service 
to calculate tlie body surface area (BSA)^ which is used 
as a common index for many physiological calculations, 
and is also used outside of the data management package 
by Uie cardiac output module* 



Caleulation Presentation 

Tbe clinician obtams the services of the cralculation evalu- 
ator through the user presentation module of the calcula- 
tions stjftware, UPC„CALC. UPC CAtC is a single (xwiponent 
Monitoring System a|ipiication that provides atx-ess to 
both calculation entry and calculation review frames. 

The ftrst step in performing physiological calculations is 
for the clinic^ian to select a pl\ysiological calculations 
group trom the set (^f predefined options: hemodynamics, 
oxygenation, and ventilation. This Is acromplishefl by se- 
lecting the api^ropriate ent:r>' key in the Patient Data array 
of choict^s. Once tbis is done, the Component .Monitoring 
System human interface software establishes a link be- 
tween UPC_CALC and the monitor display. Tln^ calculation 
entry frame is shown in Fig. 3. 

After the calculation group has been selected, tlie clini- 
cian Ciui then jierfonn one or more of the following ac- 
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Fig. 4, lk--mo(lyiuiniH:sraU!uliinQji rr\iew Tranit'. 

fioiis by u-siftg the labeled soft keys and a remote keypad 
for alplianuniene entiy: 

• Select a cak^iilafiorj time 

• Enter or edlr iT\put paranieUTS 

• Calculale output parameter values 

• Display alternate parameter yltribules 

• Print a repon lA^ the eak^ulatrons- 

UPC^CALC uses the measurement lime of ihe principal in- 
put parameter as the refi^renee time for all caleulations. 
Ill the ta^e of henuKlyTuimie ealeiilatioiis, shown in Fig. *\, 
the <*arfhar outj)ul parameter drives all of tln^ taht^r cahu- 
lations. llius the time of the last CO measurement is 
used iLS a reference. All other input panmu*tt^rs used in 
the calt'ulalions are retrievc^d frf>m tiie data management 
package chitalKise throuj*h a CALC mrHhile st^rvlce, h;ised 
on that ret^^reuie timc\ The ciJjiicJan t an choose to over- 
ride this lime by using the Change Time key to select a dif- 
fereni reference time. 

Not all input parameters used to perform calculations are 
auloiTUitieally atcjuircd by the t'omponenl MouiKuing Sys- 
tem. By using the remtric alphanumerk' keyi)ad, the elini- 
cian trail eater a numeric value for any of the ijii.iut pa- 
rameters. The clinician can also override an automatically 
acquiretl j>arameter simply liy entering a new value. All of 
these mamially entered viilut^s are storetl in tlu^ database 
and are used in subsequent calculations. 

Once all the necessary cak*ubition time imd infiut [>arame- 
ti!r changes have been made, the clinician can request 



calculations of the output parameter \^ue5. UPC_CALC 
sends a request to caiculaie the output %alues to the CALC 
module, which performs the appropriate eaJeulations. CALC 
then sends a return message back to UPC,CALC containmg 
the list of output parameter ^^ues. labels, normal rang^, 
and measurement imits. UPC_CALC uses this tnformation lo 
show Lhe output values on the Component Monitoring 
System display. 

The clinician may wish to compare the output values to 
the expected normal physiological ranges for these \^- 
ues. WTien the ON/DFF Ranges softkey is pressed. UPC_CALC 
toggles befween showing the output parameter units and 
Lhe normal ranges. 

UPC_CALC also ser\'es as the presentation layer software 
for the calculations review frame. The re\iew frame pre- 
sents the clinician with a tabular format of all previous 
caleularions perfonned for this patient. As in the calcula- 
tions entry frmne, the clinician can compare values 
against nomiaJ ranges and obtain a printed report, as 
shown in Fig. 4. TVpically. this report might be included 
witii the patient record to aid Lhe ciinkrian in assessing 
the patient's past and current physiological states. 

Conelusion 

Tlie Component Monitoring System data management cal- 
culations package provides the clinician with a means of 
reducing the large volume of raw \dtal-signs data into a 
manageable set of variables. Measures of cardiovascular 
perfonnance, blood oxygen content and delivery, and rt^ 
spiral oi"y gas exchange can be obtiiinetl through the he- 
niodynamie. oxygenaiion, and ventilation calculations. 
Tlu'se calculations are vital to Lhe ethnical diagnosis and 
prognosis of the critically ill patient, 
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Mechanical Implementation of the HP 
Component Monitoring System 

The part count and the number of different parts are dramatically lower 
than for previous designs. Fewer than ten vendors are used for purchased 
mechanical parts. 

by Karl DaumiiMer and Erwin Flachsiander 



Froni ihi} niff hanical persppctjvo, the IIP Compontnit 
Muniloring Sysiciii olleied scveriil challenges. j\iiiuiig Liu* 
most iniportaiil were the definition of the architecture of 
the computer nuxiule and liie tlesigii of the sheet-nietal 
anti i)la.stic pans ftjr U:us couij}oiierit. Other mechanical 
higltlighlJs include the iniplenicnlaliou of (he disyjlay front 
aiiNcml>ly aiul I he cojistmction of the partuiieter inociules. 

Computer Module Chassis 

The general di^sign obji'Clive for the computer module 
was to create a flexible, eompact instrimient that could 
easily be extended aiid upgiaded. In accc^rdanee with Ihe 
modular roneepi of the Compiment Monitoring System, 
the computer nuxhile hud Its he di^signed so thai I lie 
function cards coukl be luuulled as independent modules. 
All function cards were to be accessible without having 
to remove or thsiissenible tns^or parts of the enclosure. 

From Ihe production point of view, th(^ following gtmeral 

design olyectives had lo be met: 

Minimum pari count 

Muujtuun number of parts wiUi dillereni stock numbers 

Minimmn vendor count 

Use of [^referred parts 



• C'omplianet^ with all relevant medical safety standards 

• Simple and automated assembly. 

We also eonmntted ourselves to desigri ati enclosure thai 
could be assembled and serviced with only one tool (all 
you need is a screwdriver). 

The clinical environment mandates that the product be 
easUy cleaned and have no sharfi ccjmers, shari) edges, or 
deep ij {dentations. Liquid spilled over the Component 
Monitoring System is not allowed to create a luiztudous 
situation for ihe patient or the user, nor may it leak into 
the unit. Last but not least, the constraints of the elec- 
tronics had to be taken into cou.sidcration. 

The re(|uiremenl,s w^ere sometimes conlratiiclory. For ex- 
am] >ie, on one band, the chassis needs to have low RFl 
emissioris, while ort the other, it needs sufficieTit openings 
to dissipate as much heat as possible. The maximum in- 
ternal tempCTatiire rise Ciumot exct^^d 15°C. Heat manage- 
ment is made nu>re difficult liy the fact that fans are not 
acceptable in the monitoring environment. Tliis implies 
that natural convection is the main mechanism for dissi- 
pating heal. 
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Fig* I. Exploded view of the com- 
puter lutidule of the HP Cc>iuj)«> 
nent Mnnitoriug Systtnr;, 
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EKtensi%^e measurements with simulated electronic circuiis 
and caiculaiions in the early proje<-t phase were a good 
l>asis for the archltecturml design of the computer module. 
The knowledge gained from these studies and the demand 
for eas>' access to the function cards led lo the pre^^ent 
design. 

Product Design 

Two large sheet-metal parts form the enclcjsure of the 

computer module (see Ftg, I). The boltom part of the 
chassis is made of 1.25-mm-thick sfeel and has a large 
number of {>pemngs for ventilation- Mounting holes and 
pressed In threads for the instruments feet and locking 
cam are located here. The inner part of this U-shaped 
component has a nimiber of indentations and ctttouts. 
This consi ruction allows the plastic guide for Ilie function 
cards and the central plane to be snapped in place with- 
out any screws. 

The second large sheet -metal part is the top cover of Oie 
chassis. Offsei bends similar to those in the bottom part 
of the chassis make it possible lo snap the plastic func- 
tion card guide into the lid. Pressed-in threads arc 
motmled on the offset Dange to hokl the function canls 
withiti tite computer module. 

Two large indentations with sirong steel strips riveted to 
the top co\'er provide a quick and easy way to mount tJie 
14-incli display on the computer module shruild this be 
desired A combination of ittrlentations with an tmdercut, 
feet with noses, and the cam forms a tight locking niech- 
anism between the display and the computer module. 
This technique was llrst ttsed by the HP Medical lYoducts 
Gnmp in 1081 rr>r ihv HP 804()A cat^diotoc-ograph. This 
weli-es^^blished niechtmictil inUTface lor slacking instru- 
nients or attaching them to wall or ceiling mounts or 
carts was a miisl requirement. 

After the U-shaped bottom ct)V(T mid the iid of the chas- 
sis have been jissemhleti ail ftmction cards can be in- 
j^c^rted hy simply sliding Mu^ni into tlu^ pii<4osiin\ Metal 
board covers mounlcd nn \hv war (nids <jf the lun*'Uon 
cards seal the remaining openings of thc^ computer rtiod- 



A 




/' 




Fig, 2, lrisi^!r l[ii' |i?irn;illy fistsembled contpuKT nuuliilt-. 



Fig, 3. Bolloni view f)f the riinipuler iiiudtil*^ uitli unlatrhed internal 
rack iyiil sicip and roar covers, 

ttle. Each board cover contains openings for RFI clips 
and the function card's external coime<Mors. and provides 
a mounting hole for fixing the function caid to the frame 
The remaining area is perforated for veotiiation, except 
for the space needed to silk-screen tlte board name aitd 
number. Fig. 2 shows the interior of the comptiler module 
with the function cards mserted* 

As described earlier fhe function cards are held in place 
by plastic guides it\ the top and bottom parts of the chas- 
sis. The printed circuit board guide is an itxjection-molded 
part that t ;m be usefl in both locations by simply turning 
11 over 

After the top cover is installed, the left and right sicie 
covt^rs call be atlacht^i tf) the compntrr module. Again, a 
single hijection-mokled tiart fits botli sitles. This part con- 
tauis all t he vents and openings needed lor thermal man- 
agemenb Tlie side c<>vers also conc(*al the six screws that 
attach Iht* chassis top to the botLoivu The cnstonter c:;m 
easily reitiove the side covers for cleiming by unlatching 
the mtemal rack (see Fig, 3), 

Far visual and cable management reasons, a nm- co\er 
was desigtietl This iixjecti on -molded part contains 
mnlded-on pivots and latching elements. Another injec- 
tion-molded part wUh magnet ie strips gkictl on 11 1 Is the 
indentations on the top cover when the inst-rument. is in- 
stalled withoiit a display on fop (si'c^ Fig, 4). This com- 
pleles the set of plastic ])arts for the ct)m| niter modtile. 

The material used for all plastic parts except the c^hassis 
feet is Bayblend'^', a polycarbonattVABS blend. The chas- 
sis fwt consist of Iwo components: a highly filled pt)ly- 
amid for the body and a block copolymer tbr the insuh^ 
element. Tlu* cam is nuilded from polyacetate. 

Display Front Assembly 

The C omponent Mt^nitoring System can l>e tHjuipped with 
a choice of displays. The basit^ models ai'e 1 Mm h mono- 
chrome mid color displays. These displays c^otisist of IWfj 
m^jor components: the iK^zei or front ^isst*mi:>ly, and the 
display consistmg of Ibe VRT th(^ deOection electronics, 
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Fig. 4. Asseinbk^tl caniputer moduli' with iniLgrcJ pamnitUt^r iiitKlule 
ra(.'k. 



Fig, 5, Tlie display consjsls of Lhe front assenibJy and Uw display 
ilseir. 



aiui Q\v main power supply for the Component Monirormg 
System (see Fig. 5), The latter part is called the comnron 
unit. 

The common unit i.s a purchased part. To mininiize the 
number of options the vendor has to build ^md supply, 
this pai1 of the display rontains tio language-specific ele- 
ments. All options, like lot:al language, an^ restricted Lo 
tlie front assetnhly only 

Objecli^es like design for rnanufacturabilily, cliniral re- 
quirenuMits siniilar lo those for the comi3uler module de- 
sigiu and the limilations introduced by the electronic cir- 
cuits i)layiHi an imporiant role m the development of the 
(tjmptjneut MtauUirjttg Sysleni displays. 



I'he front assembly consists of a total of len pans, which 
can be assembled simply by snapiiitig the components in 
place. 1 he main element is the plastic band (see Fig. ti). 
This pjul attaclies fo the common unit.. It also serves as a 
pickup frame for the bezel, the bnttian Inleiface print t^J 
cireiiit Ijoanf a power knol>, and a proledion cover. 

The protection cover, made of thermo formed polycarbo- 
nate, sliields the human interface card from conden*^ed 
water or cleaning lluids, which might drip from tlie C'RT 
screen onto the printed circuit board. 

The bezel is attached to tJie band by snap-fit connectors 
imd presses against the rim of the CRT Since the mono- 
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Fig» 6, Exploded view ol the front 
iissenitily. 
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chrome and color displays do not ha% e tlM* same screen 
curt-atuTD, two bezels had lo be designed. The bezel pro- 
\ides room for a membrane kejixjard, wliich is the main 
control panel of the patient monitor. This keyboard is 
based on a double-sided printed circuit board. Tlte con- 
tact elements are metal domes of diftereni sizes. They not 
only make contact when pressed, btti also give a good 
tactile feedback. The domes are covered with an em- 
l>ossed poiycarbonale polyester overlay, wluch has been 
silk-screened from the rear to pre%^em abrasion of the 
nomenclature. Currently, the membrane keyboard is avail- 
able in 11 different languages. 

Design Objectives for the Parameter Modules 

The parameter tnodule mechanical design iru luded the 
developmetil of the plasiic enclosure, the connectors, and 
the overlays and the moch^mical p-art of the printed cir- 
cuit board design. Currently two module types exist: 
sjngle-widtli atid double-width (Fig. 7). The prime objec- 
tives for the design were that it be simple to insert mod- 
ules and pull them out of Ihe lark, thai the niodules be 
rugged, and that the housing be compact, measuring fmly 
100 nun by 100 nun by 35 nim. In addition to the general 
mechanical objectives listed at the begirming of this ai'- 
ticle, the t>ai"anieter modules have to meet two special 
requirements. First, they must withstand a drop from a 
height of one meter onto a concrete floor Second, for 
patient safety reasons, all connections to the patient are 
electrically floating with respect to grountl. This isolation 
betw'een floating and non floating paj-ts is tested at 16 kV 
aitd is implemented as part of the electronic circuit in 
each parameter module. 

From the electronic standpoint^ two of the approaches lo 
meet these objectives were io use stu-facT mount technol- 
ogy for mounting the electronic components, and to apply 
new ways of assembling the [)rinted circuit Ijoartis to 
achieve high jKickaging tlensity, Ou the jnocharrical side, 
new ways had to be explored to build thin-walled h\jec- 
tion-niohleil [>arts that could withstand the meclianical 
and thennal stresses luul still be durable enough lor their 
long hard hfe in the clhiical etwironmcnt. The ernire me- 
chanical design was done on the HP ME lU systetn. lie- 
fore ntaking the flnaJ molding tools, a large number of 
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modules were premolded using alimiinium tools. The ad- 
vantages were fiial tests could be conducted with 
close-to-fmal parts at an early stage in the project, and 
larger quantities could be built at a moderate cost for the 
extensi\'e prototyping phase. 

Parameter Module Design 

Tlie single-^\1dth parattieter module consists of an assem- 
bly of seven parts (Fig. 8). These include five molded 
plastic parts for the enclosune, one front overlay, and one 
primed circuit assembly. The double-width module has 
two additional parts for the housing* and in the case of 
the noninvasive blood pressure module, a complete pump 
assembly, which is built in (see article, page 25). 

The plastic housing of the parameter module is divided 
itUo an outer enclosure and an inner irame. This is neces- 
sarj^ to provide the 16-kV isolation betw^een the floating 
and noniloating grounds. Between the outer housing and 
the inner frame there is space for shielding material sucli 
as copper, mu-metaJ foil, or thin -walled steel sheet. So far, 
only tlie noninvasive blood pressure module has made 
tise of this kind of shiekling. 

The inner left and inner right frames are multipurpose 
parts for both modide widths. The double-width module 
also has an additional middle pait. 

To provide maxim tmi volume within the modules, at! plas- 
tic parts have ver>' tiiin walls. Neverthek^ss, tiiey have to 
sunlve a one-meter drop, Tliey also have to be resLst^it 
to cleaning agenLs and disinfecting solutions. We have 
found that Bayblend tneels dl these rt^uirements. Tlus 
<*ompntuul itu ludes both polycarbonate^ mtd ABS. Polyc;;ir- 
b(jnate improves the niggedness of tJie material while 
MiS iuis a iiositive effect on the chcmticat resistance. 

The printed circuit assembly within the module consists 
of three boards: a digital board including the power <!on' 
veri.er, an analog boiUfl, and a i)oar(l with LEDs and key- 
switches mounUHi on ii. The three lioiucls are irUerctm- 
nected by flexible layers soldered onto the Ijoards. For 
component loading, soldering, and test the tltree primed 
circuit btiards are handled as orte iiartially routed board 
with small bridges between thv indivitiual boards and lui 
outer frame to hold all of \h{} parts in jjiace. ( luremly, 
we have nine parameter modules in productioti, which 
represeJit a total of three different routing contours. The 
(jverall size of tlie outer trajnt* is identical lor all iJarame- 
(<T modules, tbercliy (^onlrihuting lf> our standardization 
effort by making it, possible^ to use identical pickup 
frames fc»r the dtlTerent assembly stages. At the last stage 
cif the tu'oduction piocess the three printed circuit boards 
are broken apart, folded hke a saiulwich ami inserted inlx> 
die plastic enclosure. 

Additional mechanical pails that were designed for the 
parameter modules are the patient cable, the patient con- 
nector, and the moduleio-rack connector The jj alien t 
cable connector had lo be compatible^ with HP's existing 
monitcjring equipment. One disadvantage of the existing 
system is the Umiti*d number of nu^tlianical keys avail- 
able. For the Component Monitoring Systi^m we therefore 
retlt>signed the cotutt^ctors atui extendtnl the number of 
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Fig, 8, I^^spltjded v*iew of a 
stngifi-vvidth parameter module. 



possible keys so that each parameter has a dedicated 
configuration. 

Module Assembly 

AKsembly tinip for a single moduli* is one minute. No 
screws or fasteners are needefl-all [larts snaj) fil togetJien 
The nomial assembly procedun^ includes the fV>llowing 
steps- 
Fold the printed circuit boards together. 
Insert the printed circuit assembly into the left frame. 
Snap on the righl frame (the inner module is now com- 
plete). 

Slide the inner module into tbe rear part of the plastic 
parameter housing. 

Snap the front and rear hovisings together 
Add the snap lock to the module. 

The module is now ready and waiting for shipment. In 
the last production step^ the proper language overlay is 
glued onto llie front frame. 

Conclusions 

The nieclumical tiesigri of Ihe Component Monitoring Sys- 
lern meets all of die design objectives. The E-score (a 



measure of ease of assembly) is a tiigli 77 on a scale of (J 
to 100. Only one type of screw is needed for connections 
where good grounding or stabilily is required. Part num- 
ber and part coiuU are th^aniaticaiiy reduced compared to 
fonner designs, and llie toUil vendor coiuit for all me- 
chanical parts is less than ten. 
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An Automated Test Environment for a 
Medical Patient Monitoring System 

The AUTOTEST program controls a keypusher and patient simulators to 
automate the testing of the software for the HP Component Monitoring 
System, 

by Dieter Goring 



The HP Component Moniroring System us a complelely 
new patient monitor. It is based on a tiedicated operating 
system and has an integrated data nianagement sysieitu It 
can process data from as many as 32 patient parameter 
modules and has an RS-2^32 interface for fonnectiiig a 
printer (see Fig. 1). 

Its alanii s\stem has a ver>^ complex structure. There are 
three priorities: red, yellow, and green. There ;ire alarm 
messages, sounds, and lights. Alarms can be turned on or 
off for all parameters or only selected ones. Alarms can 
be sent over the serial disiribuiion network to centra! 
stations, arrhythmia computers, or other medical de\ices. 

Automated Test Environment 

Tlie ideal test setup Tor the t'oniponent Monitoritig Sys- 
tem was easy to define. We needed a C'(jmponeii( Moni- 
toring System patient, monitor with all j^arameter modules 
installed, and we needed a human being meditally con- 
nected lo the uKJUilor to (1) provide all of the patient 
signals sui'h as heart rate, bloofl pressure, and so on, (2) 
change these signals to create alann situations such as 
asystole or low^ blood pressure {it is said that Tibetan 



monies could do this), (3) operate the monitor like a phy- 
sician or a nurse, (4) watch the monitors display and 
verify correct operation (parameier numeric \'alues, alarm 
messages), and (5) syitchronously document all events. 

Our solution to these requirements is the AUTOTEST 
application (see Fig. 2). 

The AUTOTEST application controls programmable^ pa- 
tient signal simulators which play the role of a critically 
ill f>atient (items I atul 2 above). It also controls a key- 
pusher, winch can capture aiid execute keystrokes to op- 
erate the monitor (iten) 3 above). It cannot "watch" the 
moiutor*s display but "takes a snapshot" of aU important 
infonnation (parameter numeric values, all alarm and in- 
operative messages) of the display's content whenever 
needed. All this information is sent over tiie serial distri- 
bution network evei^- s(^cond (item 4 above). 

ALITOTHST documettts a test run completely into a proto- 
col file (item 5 above). This can prove that a certain test 
case has been nm find that the unit has passed the lest. 
This is intpoilaiit, because re^ulatoty agencies may re- 
quest this data, c^ven years after release. 



Parameter Waves 




Parameter humencs and 
Alarm Messages 



Display Module 



Sound 



Computer ModuJe and Integrated 
Parameter Mos^iile ^9Ck 



Key 8«fil 



piftffleier Modules 



Fig. L HPOomponDiit Mfjnitoring 
Syslein wilh intr^gmiffi parameter 
module rark 



Otiiolier 190 1 Hewlett-tekard Atmmul 49 



)Copr. 1949-1998 Hewlett-Packard Co. 




AUTOTEST Requirements 

Th^^ AUTOTEST t>rogrBJii requires an HP Vectra ES/12 
personal computer with enough disk spare (or better, a 
large disk on a LA>J st^rver), serial imd parallel interfaces, 
additional dual senal interfaces for the simulators, and an 
IIP 78361 A serial dislrihulion network interface. Also 
needed are an HP x^UTOMAN kejpusher and at k^ast two 
L\\Tialeeh 217A progranmiatjle patient signal siruulatorji. 
Tliese simulators are widely used in rnedit'al K&I), tesUnf^, 
and training. Two tenninal portis on an IIP 300U computer 
are needed, one for the Vectra PC and one for the AlfrO- 
MAN box; 

The software includes the Al^TOTEST program package 
(written in C), AITOM^" softw^are on the IIP Mm com- 
puter, and a smart editor on the Veclra PC" for re\iewing 
tiie protocol files, wliich can be very large. 

The AUTOTEST Program 

AUTOTEST is a very simple but flexible application. It 
reads seri^dly through an ASCTl test file and executes 
each line as a command line. The following are avtulabkv 

• Commiuids to control E)\iiatech or other HS^232-driven 
simulators conned t*d to serial ports of [lie Vectra PC 

• A conmiand to send a keystroke fik^ lo I he AlTt)i\L^ 
application miming on an IIP 3000 computer 

• Commands to get the monitor's data and optionally all 
alarm messages from the serial distribution network 

• A comnuind to pause tlie test [ lets the tester read 1 he m- 
structions ) and wait for a comment or just a keystroke to 
continue 

• Conmienl lines 

• A "delay after" parameter (seconds) for every command. 

Alt commands, all comment lines, all data polled from the 
serial distribution network, and all keystrokes are ech<jed 
into a protocol file. The system time of the Veclra PC is 
also written into the protocol file before e\'eiy command 
line. Fig. 3 shows a test file xmd the corresponding proto- 
col file. 



Fig, 2. The AUTOTEST set up for 
autonipiiod f 'omponmit Monil orin^ 
System Ipstiftg, 



Loops or bnuu'hes are not [lemiiUed within a test file, 
H(^w^ever, for ea<*h test file it is possible to selc^ct the 
nurr\l>er of repetitions, and a batch feature allow^s queuing 
of test fries in any combination. 

.^ly ASCII echtor can be usi'd for creating and maintain- 
ing tesi files. 

Test File Development 

The test files were developed in ihiee steps. First, we 
wrote high-level test scripts based <yn the extc^mal refer- 
enc^e sjiecifications, covering all of the functiontility. Sec- 
ond, we gave these scripts to the R&D engineers for re- 
\ie\v. Third, we started ri^nelopment of the mocfular test 
flicks, beginning with (lie mosi important (jnes (ahimis imd 
inoptTative conditions J and I hose tluK are tedious t(j test, 
manually Tests were grouped into tO0W> automated tests, 
runs with a few manual interv^entions, semiauiomated 
tests, and manual tests. 

The test files improved in effectiveness over lime. Up- 
dates were performed constantly wlien new bugs were 
detected in the software being tested, 

Wheti fii'^I) had finished tfu^ impleineritatior) of all of the 
sysiem's tunctionaliiy (he development of all of the test 
files was also complete. Thus, for all of the defect-fixing 
rounds of testing, we ran almost exactly the same tests 
and couid show very clearly the trend of the defect rate 
(see Fig. 4). 

Resales 

With ALTTOTEST. a test cycle now takes only seven work- 
ing days. A test cycle consists of 00 hoiu^ of automatic 
tests, mostly nm o\emiglit and on weekends, 45 hours of 
semiautomatic tests, and yy bourn tjf majiual tests. There 
is also stmie destmcti^e testing by selected experts, 
w hich is done in parallel with tlie systematic testing. Test 
documentation is complete when the testing is finished. 
The system provides a complete regression test package 
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11:49:00 


### 


Si02.Pleth 


11:49:00 


### 




11:49:00 


### 


Hf O.it. continue test else press < ESC> 


11:49:00 


Test Slopped 




11:49:04 


### 


######################## 


11:49:04 


replayed automafi fife : alarm act 


11:49:17 


### 


3eml:30BPII 


!1;4S:17 


lifnl 


NORMAL SmUS RATE BPM 3D 


11:49:27 


### 


- » * verify: 




ri-.49:?7 
11:45:27 
11:49:27 


*" PULSE ~ 30 *" -^r 


Xbellfpu)"'** 




11:45:27 




HR alarm """ -^ ■ 






-\^^ 11:49:27 


vice under tesi : 




11:49:39 


Data from ije 






Parameters 








V 


KR 


3D 






\ 


Aep 


I20ai(90] 






\ 


^VP I 


4 






\ 


HAP 


12 






\ 


R£SP 


20 






\ 


Pulse : 
Sa02 t 


10 ^ 






\ \ 


97 




\ \ 


HBP 


^7- i&115lM511)) 




\ \ 


CO 


■ 7' {lOa.3 0.0 {0.0)1 




\ \ 


BIOOOT : 


35.1 




\ \ 


Tl : 


26.0 




\ \ 


T2 


35.0 




\ 


Alarms 
\'* Hfl 30 






\ 




\ 11:49:40 


^## 


' - ' Change alarming parameter to PULSE 


\ 11:49:40 


replayed automan INe : alapu 







Fig- 3. An t?xarni>k^ nf a t^.sl. TiIl* and I ho resuitlrig protofiol file. 
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thai tan be used Tor If^sting revisions and can be ea.sily 
adapted to testing new [jarameters. 

We wTote one special test ille that exercises the Clompo 

nent Mo nil raring System with very fast random k(\vfi wish- 
ing. As k>ng as tlie softwaie was nol very stable, [\m test 
file caused the system to crash fretiuently within a shorl 
perioti. With nonnal resting, we would liave had to wait 
weeks to see so niaj\y laihnt^s. TJie R^U engineers liked 
this test very much becaitsc* it gave them a gnofi chance 
to trace the software corcH'onents anrt find Ifu' f^auses of 
the era^ities quickly. 

Cojiclus^iuti 

AUTOTEST Is an excellent example of an automated 
stmctiirefi testing implementation. Even though it seems 
to lie s])ecially designeii h>r tlie Component Monitoring 
System, it is not. With some limitations (for example, no 
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keyjiushing) it can be used for lesting any HP patient 
monitor It can be used simply for a fomi of guicleci test- 
ing in winch AUTOTEST feils the test operator whai to 
do anci what tlie desired result is, and requests m key- 
stroke P for passed or F for failed. This makes it possible 



to have untrained people nrnning the tests and still gel 
complete doeumentation. AUTOTRST runs on an IIP Vvc- 
tra personai computer and is written in C, so it is porta- 
ble and can easily be modified or extended. 



Production and Final Test of the HP 
Component Monitoring System 

A vertically oriented material flow minimizes handling and simplifies 
customization. Automated final test systems minimize human errors and 
collect data for monitoring process quality. 

by Otto Schuster and Joachim Weller 



One of the keys to success in niajiufacturing a new prod- 
uct is the concurrent design or the product aiid iUs pro- 
tliu lirjii |>rocesses from ttic ver>' beginning of a project. 
Therefore, a ream of experienced nianufacturing engineers 
was integrated Into iht^ HP C'oniponeni Monitoring System 
projeet and physicaUy located in die E&D laboratoiy, In 
this way, prodnet designs and ijrodnetion process designs 
were able to influence each other l;efore all details had 
been worked out. 

The jjlan was also to transfer the product to production 
concurrerUly in Boblingen and in Waltbam, Massachusetts. 
Therefore, niaruifacturin^ engineers from Waltham joined 
our Leani to cover di\ision-spc^cifir asperts and to ensure 
producti\'e coniinunication. 

Another key to the product's success was the definition 
of manufacturing goals to which all parties were com- 
mitted. The table below shows some of these goals and 
compares the Component Monitoring System \^ilh HP's 
previous generation of bedside monitors. 

Total Fart Number Count ^7% 

Ventlor Couru for Mechanical Parts -AT)^ 

Nunilier of Printed Circuit Board Outlines -50% 

Autoloading [Percentage +27% 

Manufacturing Cycle -50% 



Material Flow 

To reduce material in process and to re<luce manufacture 
mg cycle time, it is essential to streamline processes 
wiUiout moving material back and foilli. Therefore, we 
built up a vertically oriented materia! flow. Products anrt 
assemblies can bc^ built independently up to the point 
where I hey will be assigned to a customer order (see Fig. 
t). Tins is support etl by a product stmcture that allows 
assignment to a customer order just before packaging. 
For example, the EGG modules are all built idenlieally up 
to the last step, where the product is localized by apply- 
ing the overlay label in the appropriate language. 

Final Test 

The objectives for the tinai test systems were: 
Flexibility to support different types of devices tuidcr 
test (DDT) without changing the test setup. 
Use of standard hardware. ordesi?^n and docimicntation 
of nonstandard hardwaie according to HP standards for 
manufactured products. 

Self-test ajid self-calibration features wherever possible 
to reduce maintenance. 

Accuracy based on the specifications of standard instru- 
ments diat are calibrated periodically. 
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To Cusiomtrs 

• A modular test concept that allows easy addition of new 
parameters, tliat is. eatli typo of parameter module hits 
its individual software tiKitUile U\t sfKHirualiuns, ti^st list^ 
test procerlin-e, atid drivers. 

• Ease of k^andnM and operation, even for relatively on- 
skilled personnel. This ts achieved by a high degree of 
automation, which makes il possible to operate ihe nmii 
test sysiems with v**r> little operator interaefion. In addi- 
tion, color coding on tlie display for device t^pes and 
status mes.sagcs and automatic recoj^nition oft lie device 
mider test nrv impiemeniecL Instead of manual a<1jti.'^- 
nients. calibration liaffi is generated hy the final test sta- 
tion and stored in the VA'lum of the DUT. To avoid hu- 
man errors, test results do not have to be inteipreted by 
the operator. 

• Dal a acciinnilation for statisUeaJ process control 



Fig. L HI' Crimpotieit! M^mitoring 
System prfjdiU'tifJTi nuiierial flo^v. 



Integration of Test Systems 

1lie final test sysiems me i)ased im HP !XMJO Series 300 
t'ascal workstati*ms, nmltiprogratnnters, div«^i>ie HP-IB 
(IEEE 488) instmments, and a fiaramrter module inter- 
face, which provides (he communis at ion link between the 
DUT and the workstation. All systems are connected to a 
shiired resource manager for sharing the files requirc^d for 
openttion and archiving files containing test rcsitlts. This 
incktde^s both the final test systems and the temperattu-e 
cycling test systems. 

An IlP^LlX workstation connected to the shared resource 
manager provides access to the files for other HP-UX 
terminals on a local or wide area network (see Fig. 2). 
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Fmai Test System »^ 
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Test Operating 
Software 




Fig. 2. Ifilpgration nf the final test 

systf nii; wilh II ir tenifR rature cy- 
cling test system. 



Monitoiiiig Process Quality 

To improve quality and keep il at a high level, it is impor- 
tant to anaJyze process riata online. Therefore, the test 
results of the last 200 devices of each device type are 

Dale;FriNov3016r00MEZ199Q 
Test: M10i€ PowerCor^sumptlan^Teat 
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mean = 
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= Q,9B6000 pealtmtn = ■ 
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0.024S33 sldde^^ = 
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held on disc for data analysis. Three different levels of 
uiformation can be generated. The ilrst level is tlie yield 
of prinled circuit boards or modules. A diagram generated 
daily shows trends imd can be used as a trigger for a 
more detailed analysis. This analysis represr^nts tlie next 
level and includes failure sununaries and failure hit lists 
for individual tests. I^he third level provides the distribu- 
tion curve for test results over the lest limit range aloni^ 
with the following statistical process parameters (see Fig. 
3): mean, miiiinnim and maximum values, standard defl- 
ation, Cp value (process capahihty)^ and c^k value (jiro- 
cess controllability). 

This data is not only used for process nionitoring. It has 
been tised during Component Monitoring System prototyp- 
ing lo qtuilify t-ach test and to verify the specitlcaiion 
Qmits. Thus, early information about the tn'oducabOity of 
a new product is obtainc^d well before the product Is in- 
troduced into production and valuable feedback is pro- 
\ided to llie designers. 

Conclusion 

The challenge for manu fact ii ring was not only that the 
Component Monitoring System was a new product, but 
also that it was our llrsi product designtnl in surface 
mount lechuologj' and the fust inoduct for the Boblingen 
surface mount lechnrOogy center. The parallel nnnp-up of 
production in Boblingen and m Walt ham lias proven that 
concurrent pro<lucUon process design is not just an alter- 
native, but rather the only way to succeed. 

Ac kn o w I e dgm en in 

We would like to thank all of the people who contributed 
to the design and implementation of the ( -omponeni Mon- 
itorijig System manufacuiring process, in partlctdar 
Giinler Ilasert, Wolfgang Strenzl. Frank Keil, an<i Dieter 
Frank from the Boblingen Medical Division manufacturing 
development enginetTing team and Fr'cmk Lyons, George 
KinziCj and Cliris Leary from Uie W' alt ham Di\1sion. 



Fig, 3. Mt>al test analysis. 
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Calculating the Real Cost of Software 
Defects 

Using data from a weii-estabiished software metrics database and an 
mdustry profit loss model a method is developed that computes the real _ 
cost of dealing with software defects. 

by WiUiara X Ward 



Ih response' 10 the HP cQri>orate'Wide 10 x software qiialj- 
ty mipro\x"ntent initiative, mucli attention has been fo- 
cused on ijnpro\'iiig the quality of softwaiG products de- 
veloped throughout HP. Tlie motivation for software 
quality iinprovenifnt is most often exjiressed in temis of 
increased cusiomer satisfaction with higher product quali- 
ty, or more gentnaily, as a need to position HP as a lead- 
er in quality softwart^ develop ment, 

A more fundamental motivation to support the initiative 
for higher software quality can be developed when soft- 
ware defect cost data is c^onsidered. The data presented 
in this paper is cirawn from an extensive snftv^are project 
database maintained at tlie IIP Walthani Division Ibr prod- 
uct releases over tlie past five years. When software de- 
fect cost calculations are pcTfomted on this daJa, a very 
compelling? "htMlom hn(^" perspective on softwiue quality 
emcrj^cs; soflware defects are very expensive and early 
defect prevention and removal techniques can substantial- 
ly enhance the profit realized on sc)flware products. 

This paper will present a general model that can be used 
to calculate software defect cost data for any software or 
firmware product. Data trom actual IIP VVallharn jjrojects 
will l>e used to provide examples of software cost calcu- 
latioits. 

The N*eed for Metrics 

As an exampU^ ol the need for substiintive software quaU- 
ty cost data, consider the situation a projetft manager 
might encounter when attempting to justify the purchase 
and tise of a new software develoi^ment tool such as a 
statu* code anal>-zer If I he cost of the tool is S2(),0()() tmd 
if there is rehable data to suggest that the tool wiil un- 
cover 5% of the total number of software defects during 

Soltware Developmenr Phases 

RequlfairenEs Analysis 
Oeslgn 

Codf 
Unit Tear 
f Integra Hon 
■Metrics J Sysi&m and Acceptance Tests 

Darabasie i Release 

\. Postrelease 

Fig. I, SuftwrirT' life t ytlp md iht* pli:ist^s llu' fioftwart* quality 
unginet^riri^ nir tries flat abase cav(^rs. 



typical use, is the project nianager justified in acquiring 
and using the tool? 

To provide answers to tMs type of question, it is impor- 
tant to have access to a reliable database of software 
quality TUetrics. Such a database is maintained by the 
software quality engineering group at the clinical systems 
business unit of ilPs Waltham Di\1sion. This database has 
become an essential cornponeni of software iiuality actixi- 
ties at HP Waltham and is inxaluable for such tasks as 
project scheduling, resource plamiiiig, project and product 
quality status reportingt and softwai-e defect cost calcula- 
tioi^s. 

In addition to maintaining the metrics databtise, the soft- 
ware qudity engineering^ group works witli li&D in testing 
and process improvement activities. 

Software Quality Metric** Database 

Fig, i indicates I he dev(4opmeiU phases of a typi<!al soft- 
ware pnjject, with the phiLses indicated in which metrics 
are collected arid stored into the software quality data- 
base. Data is gathered from a variety of sources including 
softwaie defect logging, product comparison studies, pnij- 
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Fig. 2. Sipflwaro dpfct i ftiirt and fix (:sii.^Ki. 
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ect posl-niorlent stutlies, code complexity and size analy- 
sis, and projrrt schedule and resource plans. The physical 
data reskles mainly m a standard IIP STARS* database, 
which has been augmented witb additional fields, files ^ 
and rejxjnlng ulililies. All of the products represented in 
the metrics database are firmware-based niedical ^levices 
such as critical care monitors, aiThytlimhi analysis com- 
puters, and clinical databases. 

Figs, 2, 3, and 4 represent various types of useful data 
that cai^ be extracted from liie database, Fi^. 2 docu- 
ments the steps that aic topically requirt^d lo find, Tix, 
and retest a defect discovered by the soft wart* quality 
engineering group during integration and system or accep- 
tance^ testing. Tlie engineering effort for this activity, 
which is shown as 20 liours, represents the average efftjrt 
for fmding and Ilxing one typical software defect. Tlus 
value has been caU^uIated using hundreds of data points 
from mulfii)]H software projects that have bc^cn tiaeked 
with the soft waif" quality dalabiise. Fig. 3 is an example 
of how B.n accurate schedule tor the mtegration through 
tlie release phiises can be developed using historical proj- 
ect data from the database. In this case, it is clear that a 
stable antl linear relationship exists }nnw(*en product ccjdc 
size anrl Resultant calendar time. Finally, Fig. 4 tabulates 
various softwart^ metrics from multiple software projects. 
This data can be very useful for developing project com- 
parison studies. 

The data presented ui these figures is a small subset of 
the <!at;i that exists in the database. Tliis specific data has 
been presented because of its applicability \o soft ware 
defect cost calculations. 

Looking for Software Defect Costs 

Software defect costs can be investigated using a variety 
of different approaches. For example, costs can be calcu- 
lated on a prerelease or a postrelease basis, or costs can 
be (k^temiined per defect or per project phase, oi^ costs 
can be wc^ighted based on code size or prograrnnier pro- 
duci:i\ity. The software defect cost data devcHtJped in this 
paper focuses on the cost per prerelease soft ware defert 
that is found and lixed during the iniegi'ation througli the 



'Ihe Software Tracltfng and Reportirig Sysieni, or STARS, is an HP internal database 
Far tracking soflwara defact$, 
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Fig- 4^ T^iJical s^jftware metrlcts for projectfi in the softwiin? quality 
database. 

release phases of project developiuenL Tlllg approach is 
used because of the abundance of reliable data points 
available for study and because of the potential utility of 
the result^s. 

The Software Defect Cost Equation 

The calculation of prerek^asi- software defect cost pro- 
posed here is based on tlie fumiula: 

Sofl^s^are Defect Cost =t Software Defect Rework Cost 
+■ Profit Loss 
Software defect rework cost is detenu inetl by the amount 
of effort and expense required to find and fix software 
defects thiring tin- integration ihnutglt release phases of a 
softwaie prqjeci. Profit loss is the revenue loss that is 
caused by lowt^r i> rod net sales throughout the entire post- 
release lifetime of the product. The lower sales factor is 
caused directly by the lengthy find and fix cycle of pre- 
release defects that force a schedule shp and result in a 
loss of market-window opt jo rt unity. 

Many other factors could probably be used to detenuine 
the software defect cost but our data shows that the re- 
w(jrk cost and profit loss factors have a m^yor impact on 
the result and will supply a close first approximation of 
the final value, Tal)le 1 lists a set of prt>duct and project 
scjftMare factors that will be used to calculate a software 
defect cost value. All of these factors represent typical 
values derived from our database. 
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Software Defect Rework Calculation 

This calcuJation is very simple and is based on data pre- 
sented in Figs. 2 and 4 and Tablp 1. A tvpical product wil! 
have 110 software defects fountl and fixed during the 
project test phase. Each of these defects will require 20 
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rngiBeermg hours to find and fix The total prerelease 
software rework effort then is: 

Software* Defect Eework Effort - 110 x 20 ^ 2200 
engineermg hours. 

To convert this effort ^'alue to dollars requires the $/hoiir 
software engjneer factor. As a close approximation of an 
!ndustr>' standard value, we will use $75/hour as the sam- 
dard charge Tor Ihe semces of a s*»ftware engineer. (Tliis 
includes basic saJar>* + adniinlsiration overhead of 75%). 

Softwan? Defect Rework Cost = 2200 hours x 
$75/hour = $165,000. 

On a per^efect basis, rework cost can be determined as: 

Rework Cost per Software Defect = 20 hours X 

$75/hour - .$150(). 

These calculations are useful In highlighting the tnie 
waste factor of poor software quality. Each software de- 
fect is responsible for $15(X) of uiuiecessarj^ expense, and 
for a typical project $166,000 is required for software 
rework. 

Software Defect Prtjfit Loss Calculation 

The other niv^or factor conlrihuting to software defect 
cost is pruduci profit lt>ss ht^iause of niissed nuu^kc^t -win- 
dow opportunities and the resultant loss of product sales. 
In other words, if a produf t release date slips bcK^aitse 
the software defect find and fix cycle is tinnecessarily 
long, then potential product sides are irretrievably lost 
and overall lifetime profit dollars will l>e less. Such fac- 
tors as rapidly oijsolete technolo^v aiul the availability of 
contpetilive jjn>duct~s also contril)Ui(* to the potential loss 
of salt^s. 

Several industry modeLs '-^ have been pixiposed thai can 
be used lf> quantify tlu- iirofil loss factor. Fig. 5 p|-esents 
one of these in(jd*'ls m\d will sene as lh(^ l^asis for our 
calculalitms. For the foilowiiig t alculaticjns wf assume a 
1000-unit tnisloiucr base of a $20.iKJn product with a i'f/u 
prom margin. Tliis will yield $:?,00t),tKM) in lifetinie pn>nt. 
Assuming a six month slip in product release because of 
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Fig, ©, Software defect cost suinjuar>' for a typical software 
project, 

the software defect find and fix cycle. Fig. 5 suggests a 
33^> loss in profit* 

Profit Loss = $:l,000,000 X am - $1,000,000 

lising the data on the number of prerelease defects given 
in Table 1, on a per-defect hasis, profit-loss can be deter- 
mined as: 

.$1,000,000/110 defects ^ $9000 per defect. 

It may seem extreme to say that every i>rerelease defect 
causes a product to be laie to market. However because 
of the nature i>f our business, it is important that our 
products perfomi reliatily in the critical-care medical envi- 
ronment. I^iis means thai each defecf of a high enough 
severity It^vel that is found during prereleast* tests must 
be fixed aiid retested before filial release. It is this test, 
fix, and retest cycle that delays product release and con- 
tributi^s !o the cosi of i>oor software quality. 

The $1,000,000 Opportunity 

Fig. *) sumiuarj/A'S the software defect Cf>st data calcu- 
lat(»d in this papcT. The variables ust>d in these calcula- 
tions will vat>' from otu* organization to another, but the 
fundamerUal algi>rithm fur computinj^ software defect (^ost 
is applicable^ to most ctises. Although Ihe prfxiuct cost 
and profit margin numbers used here are for il!us*rative 
t>urposes. they Mf: typical lor large software systems. 
Then^fcue, with the polential for a rost of SlO.'iOO tier 
defect and $M(35,O0<J per project, there is amjile Huancial 
basis for a number of polential remedial actions. 

Quality Awareness. Most softw^are engineers probably have 
no idea ahoiif the cost of rew(jrking S4jftware lo find and 
Ox a direct once the code enters die integration and test 
lihases. They should hv made aw^arc^ of Ihe savings possi- 
tde if more deled detedion could be done in the early 
stages of product development, 

CASE Investment There are a laj'ge number of CASE tools 
and miMhoddlni^ies available to augment the software de- 
VivlotJiiuH^t pHHi'ss. Examjiles of modent CASE technolo- 
gy iiK'lude static cod<* analyzers, debuggers, execution 
profilers, fom\id insp(*ctions of design mu\ code, struc- 
tiimd analysis and tlesign, and so on. Most of thest? tech- 
nologies can lie acqiiired for a financial investment of 
$10,000 to $:iO,OI)(t If each softwaie defect has a $10,500 
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cost, then it is clearly appropriate to consider the use of 
CASE In improve ?i;:iriw?ire^ quality. 

Software 10 x Program: When it becomes clear iliat soft- 
ware quality improvc^ments can yield subsianiial financial 
rewaids, then the goal of a lO x gain in software quality 
assumes additional imfjetiis. Consider I hat a 10 x im- 
provement of the mini her of prerelease software^ defects 
for the fy|)i€Lil software project presented in ihis paper 
would yield almost an additional $1,000,000 in profit. Thai 
figure is a powerful bottom line mo ti vat on 

Conclus^ion 

This paper has presented a technique that can bo used to 
(calculate softwaie defect c<jst values, llistorit^al lU* WaJ- 



tham software quality and project data has heen applied 
to cost calculations s(j that reabstic results might he ob- 
tained. Althougti additional investigations, such as a deter- 
mination of postrelease software defect cost, migi>i pro- 
vide a more detailed analysis of cost, the data presented 
in this paper is accurate and provirles cxnupelling finan- 
cial motivatii^n for improved softwitre quality. 
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A Case Study of Code Inspections 

The code inspection process is a tool that can be used early in the 
software development cycle to help improve the quality of software 
products and the productivity of development engineers. 

by Frank W. Blakely and Mark E. Boles 



Code inspections have Ixx-onu* an integral p^irt of the 
5oftw£uo develupnicnl life t\yck^ in many organizations. 
Because ii lakes some projoei I hue and because engineen^ 
initially fee! intimidated by the process, code inspections 
have not alv^ays been readily accepted. Additionally, there 
Jiius tnH always l>een enough evidence (metrics) lo prove 
that for the Ijme and effort iinested, the process has any 
value in reducing dt^fecis and impro\1iig overall soft:ware 
quality. Since the early days, tiie process has become bet- 
ter understood and docunicnfcd, and recent articles have 
provided concrete me^trics ku\d other evitlence to jiLstify 
the value of the process. ^^^-^^ 

This paper desrdbes our exf>erienees in hnii^inj^ die code 
inspection pro<*ess to HP's Application Hiippoit Division 
(ASD). We describe both the positive and negative find- 
in ^s related to using code inspections. jM though we only 
have metrics for one project, our main goal here is to 
present how^ we impleinented I he inspection process and 
to llhistraie lite ly^w of data to collect and viiial might be 
done with the data 

Background 

In 1988 our division was in the process of searching for 
best practices imd methodologies tJiat could help us meet 
or exceed the company- wide 10 x quality improvement 
goal. Design and code inspections w^ere Ia^d o[ the meth- 
odologies that we proposf^d. Management agreed to sanc- 
tion a pilot project asing code inspecnirjtis, witJi imple- 



ntetUation of a design inspection process deferred to a 
later date. 

Tlie auliiofs attended the software inspections class given 
by liP's Coiporate Engineering software engineering train- 
ing group. This knuwletlge was then imi>orte<l lo our divi- 
sion, and sevend classes were laught to tht^ engineers to 
prepare tliem tti he participants in die code inspection 
process. 

To begin using the code ins|>ection process on a j^ilot 
basis, a scjftwait' prcjjtHt that involved enhmic'ing an exists 
ing product was selected. To ensure that we could im- 
prove the process and leani from our experience, we de- 
cided to record and analyze the results from each code 
inspeclion. This way we vvould liavt^ sonu* data to back 
n\i m\y claims w^e had regtu^ding the value of the j)rocess. 
The metrics and data we decided to coOecl and analyze 
included; 

• The triterJa to use in sele'Ctiiig modules to inspect. 

• 'fhe criteria for selecring particnpanis in the |)rf>cess. 

• The methodology used vihile perfonning the uispection. 

• The relative effectiveness of code inspections in improv- 
ing quaMty versus standard testii\g via module execution. 

• The nierits of doing ctjde inspections before or after 
bench testing a software module. 

• The nunibtT of defects found in a product in Uie first yciiJ" 
after release tliat might lia\"e been found in code uispec- 
tJons- 



58 ( hr ot H ■ r ]W\ \ I rw M\ -Pixe.kMd Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



• T^e cc^ts of addressing defects found in the first year 
after release during tht* inspection phase \ ersus during 
the niainienance phase. 

Engineers fn>m the quality and productivity department of 

our division taught the inspections class l>efore starting 
the pilot project. They also acted as nimierators for the 
formal code inspections. R&D software engineers from 
st'verd! different pnyects participated as authors, readers, 
and inspertorB. Thert^ was also a technical marketing en- 
gineer who participated as an inspector 

Implementation oflhe Code Inspection Process 

Developing a set of criteria for which modules m inspect, 
who should participate in the ii^spections, and whal nielh- 
odolog>' to follow were the first issues thar needed to he 
resolved in tmiilemenling the iuspeclion process. Two 
methodologies were used in our implementation: formal 
and informal inspiH.'litJns. Tlie t*ilot prtyect used the for- 
mal, more sinictured prcjcess t^resented in the inspections 
class, while later projects iLsed botli fonnal and infoniial 
methodologies. The comjjarative success of the* two melli- 
odohjgies has not been fully dctenuined, but some of the 
results are described later. 

Module Selection. Because a software product is made of 
Mumy muduli's. the time it would take to inspetl eveiy 
module might be prohibitive. Therefore, criteria must ex- 
ist to determine which nuxhtley shouki be insi)ected. Two 
criteria were usetl to identify the mi>dules lf> l>e in- 
spected, FiJ-st, modules were selected only if Ihey were 
motiilled ui the course of the project (remember this was 
an enhancement project). Second, ihe complcxiiy of the 
tuiKiined modules was detenuincd, Module complexity 
has iieeii shown in be a gof>d indicator of tht^ tlcleri 
proneness of a software modiik> — the liigher the (complex- 
ity, the greater the llkeliliooci liiere are defects. Therefore, 
complexity wuti u^^d to identify I hose modules thai were 
the best randidates tor insru'ction. Tiie cjriginal iilan was 
to deteniiiiK* tlu- ronv|)k^xjty ol' mtMlules usin^ die 
Mc('abe complexity tofd.^ which is baseti on the Mct'al>e 
complexity mc^tric,'* I 'nfortunalely the McCabc tool could 
not accurately identify the complexity of tiu^ rnotiules 
vvntten in MSdKJS macro assembler taiigna^c. This led to 
attcmiHs to roughly quaivtify the e(*nii>lcjvhy of these mod- 
tdes, relying on the opiition of the modules author as to 
its complexity The result was that modules were In- 
spi'iied l)ascd on the ^imount of modiOeation to the mod- 
ule ^uid a rougli estimate t>f tliehr complexity. 

ParticipafTt Selection. A code iuspectirm is a struct uied 
priKvss iti wlurb each parii*^ipant has a clearly defined 
role. Inspection participanis were st*lected based on dieir 
kjujwlcdge of the language in which the mottule was writ- 
ten, Altcmt>ls were :ilso mack* to sckx1 engineer's who 
were also knowledgeable abcaU the high-level stmcturc of 
the product. We cotdd not Imd many cngineei-s with litis 
knowledge so this crilerion was abandoned and knowl- 
edge of the developtnetit Uuiguage becatnt* the [iredijiiu- 
iiate c rit err t>n. 

Fonnal Cotle Inspections, fhe methodology we used for 
loj'iual eodt* inspections nnjuired thul tin* author select 



the module to be inspected and prepare inspection pack- 
ets for the moderator, code reader and inspectors/ The 
cocie inspection packet was distributed two days before 
the scheduled inspection date. The packet consisted of a 
cover sheet and listings fmth line mmil>ers) of the mod- 
u!e to be inspected. The cover sheet detailed the time 
and jJiace of the iaspection meeting, the participants, and 
a brief description of the module to l>e inspected. Be- 
rause some of the engineers who panicipated m inspec- 
tors and readen? wesv^ unfamiliar with the design of the 
modules, additional information was .sometimes added to 
the packets lo improve the effectiveness of the process- 
Additions included module descriptions, pseudo code, and 
design overview documents describing the design of the 
module. 

Before the meeting the moderator was responsible for 
conflmung the availability of the meeting participants for 
the litne and tiate of the inspection. Inspectors were re- 
quirt^d to iacp^u"c^ for the inspection, anti if they could not 
guarantee afkHjuate t>rej>aration. notify the moderator so 
that the inspection coukl be reschedtded. I'sually on the 
the day before the meeting, tlie moderator would check 
to make sure that everyone was ready 

During the meeting the following ndes wer^^ followed to 
avoid conllicts ^md ctvsure a productive pri)cess. 

• Critiques of the (*oding style used in the modide being 
inspected were avoided, 

• Problems were to be indicated and identified, but solu- 
tions were not to bv offered during the inspection meet- 
ings. 

• t'omments were to be tduast^d in a uoutlucatcning way 
fot using on what the module dkl, as cjpposcd to wlvat the 
author might have (kme. 

• Antagonistic ways of expn*ssing points of view were 
avoided. 

The meetings were limite<l to one hour. Data from other 
di\isk)ns showed that longer meetings rlrained Uie uispec- 
ik)n team and fie creased their (Effect ivent^ss. 

IVo forms were tisinl to gather lire data from the code 
ir«spe< tions: the code instKMlion log and the code irLspec- 
liou iietall log (see Fig. 1). The code iuspectitjn log fie- 
scribed the module inspected, the participants, their prc^p- 
aration time, the hours of engineering effort in%^olved, the 
muiiber of lines inspectetf and ibe lUJiuber n( ijrohlems 
idenliried. The deh'cts ifk^itifird wcTe categoriztHl by se- 
verity, aiid whcthtT ami how tliey coukl have been found 
m tlte abs**nce of code inspections. The code inspecdon 
ckHail log idt^ntified a prolilem by page and hnc^ number 
in the nKwiuk' source, antl provided a description of the 
problem and its severity At the end of the meeting a de- 
cision wijs made as to the advisability of scheduling a 
I'oinspection of thi' module if lite mtmber of i>roblems 
found was unaeceptable. If Ihe avilbor madt- extensive 
changes to liie inspected nuKiules wfiile fixing inspection- 
identified defects, this would possibly create a need Ibr- 
reinspeclion. 
'Wii atsually had rwo «nspector.s The authai act&d as an ifispector. 



UrtotHi IJfMl Min^li^ri I'ar k:srtl .tfitiriiEt! 59 



)Copr. 1949-1998 Hewlett-Packard Co. 



Page 
TEAM 


CODE INSPECTION LOG 


MODULE 1 


rn RF irjsPFCTFn 








ROLE 


NAME 


PREP MEETfNG 
TIME TIME 


Author 

R&ader 
Inspector 












Total TrrriE 








TOTAL EN 
NUMBER ( 
TOTAI 

NUMBER ( 
TOTAL 


GR EFFORT 


# LINES 


3F CRITICAL PROBLEMS 
BV PROD.<;Yti TFRT 


BY CUSTOMER 


DP NONCRITJCAL PROBLEMS 
BY PROn.RY.S TFRT 


RV ni fSTOMFR 







-^« ^' '^TEir^^f' -- 




Prob 

no 


Page.' 
Line# 


problem Des-cnptlon 


Seventy 


































































Stiver iry Critical Npncntical EnhancemenI 



ta] 



«U) 



Fig. 1. (a) Code Inspf^f tian log. fb) Codf insppf tiun fief ail lisg. 



In the postinspeclLon meelings, the moderalor aiid the 
author ntct so ihat I he mod(Taiur could ^ive the collected 
informal ion lo dvc author 11ie author was dieji responsi- 
ble for ijnplemeniirtg the defect repairs. If enhancenients 
had been identified In the insp^'Ction, 1hes<* wert^ either 
accept ecJ or reject erl by the author an<i the moderator 

Informal Code Inspections, Informal code inspections were 
not a part of the isMot project. Several inRmjial code in- 
spections were perfornied on laler pr ojects and as a part 
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Fig. 2. Suntniar^' of code inspection statisUca, 



of the pilot project's CPE {(rurrenl product engir\cenng) 
or postrelease actmties. Thert^ was no prepiu^ation re- 
quired for these infomial code inspections. The code's 
author would request that another engineer sit and look 
over a inothile or a snbnvodule at the time of the meeting. 
There was no rnotieraion and no formal tlocumentalion of 
the process. Usually, the engineer' who was asked ti> in- 
spect was fajiiiliar with the overall design of the inpdule 
being inspected. 

Data Collected 

j\s mentioiuMl earlier we tried to collect cJata that would 
enable us to evahiale the effecli^'euess of the code in- 
spection process. The code ii^spection data collected in- 
cluded the number of: 

• Lines of noiu'onuuent source statements (NCSS) in- 
spected 

• Engineering hoivrs cjf preparation rt^iiiired 

• Engineering hours spent in code inspection meetings 

• Defects and enhancement requests fomid during the 
meeting. 

Because tlie effort, required to fix a defect is the same 
reg*ii cliess of how it is fomid, no data was collected on 
the time taken to fix defects or implement enhancvments. 
Alscj, because the unplemeination of the iufomial coile 
hisiJection process was done in a way ihat jjcmiitted a 
wide variation in the statistics collected, iasufficient daia 
exists to detemiine clearly the effectiveness of Infonnal 
code inspections. Fig. 2 sumniarizes the statistics from 
our pilot project and some follow-on projects in whirh 
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Fig. 3. Major modules tmcl pftrcenl of code |j\spe<itHl 

both fomiaJ and informal code inspection processes were 

used. Fig- 3 shows the ni^or niotJules and the amount of 
code inspected from each module, 

FVom the data showTi in Fig. 2» the ratio of preparation 
time to inspection time can be calculated as 1.83 for the 
pilot project, and 1.13 for the formal inspections done Tor 
a follow-on project. The raiio for all of itie projects was 
1.76. Tlie inspection rate for the pilot project was 200 
lines of NC:SS per meeting hour' For the follow-on j)roj- 
ect it was 196 lines, bringitig the overaU rate to 199 lines 
per meeting hour. The defect finding rate was 0.243 de- 
fects per engineering hour (preparation houre plus meet- 
ing hours) for the pilol project and 0. 1 IB for the follow- 
on project, bringing the overall defeet Imding rate to 
0*233. Work done by other IIP divisions showed that for a 
one-hou!- meeting, 2(}i} lines of eode is about the most 
that can be c<jvt*n*d hetbrc^ the defet^t fmding rate t>egLns 
to decline. 

Tlie metri<*s for preparation time and lines per meeting 
i'iin be used to estimate for future projects the amount of 
lime rei|uired for inspections so thai projects can budget 
hi their scliedules a reasonable amount of time for in- 
spections. Th(^ iierect rinding rate can bt^ ust-d to corre- 
late between the effectiveness of different types of testing 
atid the complexity of rnodides so that the overall val rela- 
tion of the cotie design can hv opiinii>;etl. 

During the development pha^e of the pn>Ject, test log 
sheets were ust^d in (^olletM data about di^ftx-ts found dur- 
ing testhig and the nuuiber of hours devotiHl to testing. 
This data was used to help analyze traditional testing 
versus code inspections. 

Defects n^ported by customers against tht* pUoi product 
during the first yeju" aft(M* its release w^ei'<^ also (^4>llecled, 
The olije«1ives of gathering (his data were: 

• To detennine wluMher Ihe detects were in mo<hdes that 
had been inspected 

• To dettTmine why. if tlu^ defects were in inspected mod- 
uU*s. Itiey were not hnuut during the irLsprttion 

• To determine why UKidules with defects were not in- 
si)ected 

*Faf eacli farrnal inspcctJQn, fheru wen? 4 pamtipaius and a total □! 30.4 hours were 
spent in mEetir>g.s ThuE. 304.erkgifiRijrii>g hours iH meetmcjs equals 7.6 meeting hmfs, 
TasuUing m 200 lines pel meetsng hoLir ( 1 51B lines/? B meeting hours} 



# To determine the relative costs of addressing the defects 
found by customers comparetl with tJie tost of putting 
more effort into performing code inspectiona 

Tlie data collected also included the number of hours of 
online and offline support spent identifying and verifying 
the j)roblen^, the number of engineering hours spent 
identifying the causes^ Ihe appropriate fix for the defect, 
imd wtieiher the modules in which the defects were 
found were inspected. Additional information rdlowed 
estimation of Ihe time required to perform code inspec- 
tions on those nicHiules not inspected. 

Comparison to Testing Process 

For comparison with the traditional testing process (i.e., 
mcnhile execution), defects for the pilot project were 
categorized according to the metiiod itsed to rnu] ihe de- 
fect and the defect cause. Fig, 4 shows tiiis caiegrjrization 
for tlie pilot-project defects. Note the inclusion of custom- 
er-found defects. Fig, 5 show^s the severity of defects 
found classified by severity and tesl type. Note that in- 
spections found defects in each of the standard severity 
categories. 

Pigs. 4 and '> do not reflect comment defects or defects 
resulting from inconect tlesigr^ Both types of defects 
w^ert* found and noted but not coimted. 

If Inspections Had not Been Done 

The defects found by code inspections were analyzed to 
fletemiine whether they might have been found if code 
insiiections had not l>een done. UTiile Ihese classifications 
art' rvt>i ceriairh tht>y were our best determination biised 
on knowk^dge of the product, the test environment, and 
the way in which the product would be used. Fig. 6 
show^s wtiere in the proi^ess we think certain defects 
would havi' been found if iliey had no! been caught by 
code inspections. 

As a further aid in analyzing tlte effectiveness of code 
iosptH'tions as a verificarion tool, the defects foiutd during 
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Fig, 3. Defecls tialegorLsecl hy severiry tttnl methixl ol delecUon. 

uij^pecllons were divitleti into fategories biised (m the 
following questions about each defect. 

• Would the defect have been found by the existing lesl 
process? 

• Could a test be de\dsed to llnd those defects that would 
noi be found by existing tests? 

• Would customers find those defects tlial would not be 
found by existing tests? 

• Won it! some nf these defects not be fomid by any of the 
above niediods? 

Of the 21 defects found by cotU^ inspections, only four 
could havf^ been found witli nt^w tests. 

Defects Found by Customers 

An analysis was mnde ol the defects found bj|t ^^lits^lfiters 
m the lime sij^ee Ihe iiilol protkirt was released* Tllis 
allowed us to attempt to detennine why tJie (iefeets were 
not identified and fixed before the release of the product. 
Fig. 7 shows the distribution of defects found by custom- 
ers and the reasons associated with tlie defects. Tliese 
reasons include: 

• The defect was a global eiTon not speeilic to a module or 
modules. 

• Tiie defect existetl in a dependent product. 
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• The module was not inspeded because it was not modi- 
fied. Tills also indicated that our test suites w^ere not thor- 
ough enough. 

• Tlie module was not inspected because moditlcations 
w V re not con s i tie re d sign i l"i c ar^ t. 

• The module was inspected, but the defect was not identi- 
fied. 

The defects ciassified in the first two categories were 
those for which a code inspection could not have identi- 
fied the defect. 

The cost of ha\ing customers find defects in the product 
rompared to tlie cost of using code inspections to tnid 
these defects was measured hy collect ijig cost intomia- 
lion trom dte respot^se center,'^' sup|>on engitveering, R&.0, 
and test and manufacturing. The average time of a re- 
spor^se center call was deteiiuined and used lo estimate 
tlie responst^ eenter cost of handling a defei t. I'he tost of 
the time spent by the support engineer was determined 
based on the time spent in responding to calls at) out de- 
fects in the product. The cost of the time spent by devel- 
opment engineers was based on the time spent identifying 
the cause of the defect, the time to fix it if necc^ssary, 
antl ihe time required to test the defect once it was fixed. 
Estimates of tlie time required to j.ierfomi system testing 
and die manufat turing costs were also coiieclefl. The 
results showeti that it cosls ajjproxin lately 100 liuK^s 
more to fix a defect in a released product t.hmi it costs to 
fix a defect during the code inspection phase. 

One important cost that cannot be directly measured in 
cimency is the loss of customer satisfaction when tlie 
customer finds a defecl. Because this cost is hard lo 
quantify, it is sometimes ignored, but the fact is that it 
does affect the profitability of products, 

*The rE.^pfiniie center is tt« primary coniact fof customers and HP faeSd persorirtEl to obtaxi 
he(D wilh HP software. 
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BeTtefits 

Besides the cost saiiirgs realizecl by finding and fixing 
defects before they reach the customen there are other 

benefits associated \^iili doing code inspections. These 
benefits are not easy to measure, but they do have an 
impact on quality and productivity. 

• Code inspections aliow defects to be found eariy in the 
prttduct developnu-nt cycle. litis has ihe iTenellt of reduc- 
ing l>je niimber of produd builds and rerrification cycles 
required to complete the development of a product. This 
benefit is difficult m qiianUfjf because there is no way to 
measure the btiiJd cycles that might be required for a giv- 
en number of defects. However, one proiiuct build and 
certification cycle is a nunimmn of 40 hours in our envi- 
rc*imient. 

• The code associated wit h a defect found during a code 
inspection is Iruniediately identified at t!ie inspection. 
When a defe<1 is found by testing, all ilial Is known is that 
somelhing somewhere doesn't wtjrk coiTectly, and the 
additional work necessary to identify the lines of code 
that aie at fauli is unknown. 

• Because code inspections re^iuire a great deal of coninni- 
nicaliou aniong the participants, cross training and idea 
sharing are byproducts of the inspection process. Other 
eitgineers involved beccHue familiar with moduk*s they 
did not write, and acqtiire a better undci-standing of the 
entire product. Also, engineers from other projects ac- 
quh*e a better understanding of protlucts other than their 
own. 

Issues 

Four issues came out of the code inst>ection prof;ess. 
Tliese were in the area of proc^edurt^s or aspects of the 
implementalion rather than condemnations of the process 
in general. 

FirsI, Ihe primao' t (insider: tt ion in selecting utspectofB 
was their ahiliiy In mu\ and coniprcluMul tlu> pn>gram- 
mhig language being instteclett A lack of ijiifk^rstandiJi^ 
of tiie <iesign was nol considered an jmijc^dituent to piu- 
iicipation. However, this was an impediment to making 
Ihe insfiections as I'tfeclive as possible because the in- 
spectors could not always effectively identify situaiifms 
where the implementation diil imt nuUch Ihe imcntleit 
design. 

This led lo tlic stn^taid area of difficully -the need for 
formal design reviews. The lack of hjnual design re\iews 
results in cnj^ineers utJtside of the project having little 
familuuity with the details, ur even in some last^s with 
the overall design of a product. A lack of a dt^ign review 
process inhibits the effetniveness of code inspections on 
projects with a small nttmber of engineers- 



The third issue Involves deciding when a module should 
be inspected. We deiemiined that the code inspection 
proi^ess should be used after the developer believes that 
the designed functionahty is correctly implemeiued, and 
t)efore testing is done. All inspectors and readers should 
be familiar with the overall product desi^ and the imple- 
nientation of the module being inspected. 

Finally, the defects that were missed and could have been 
found in the inspection process indicated that we need to 
find a way to improve the methods used to identify po- 
lenliaJ defect areas during the process. 

Conclusion 

Based on the data collected about the use of code inspec- 
tions, and the data concerning the cost of finding and 
repairing defects lifter the product has been released lo 
the customer, it is clear thai the implementation of code 
insiK^ctions as a regular part of the deveiopnient cycle is 
beneficiid compared to the costs dissociated with fixing 
defects found by customers. 

The formal code inspection process is a significant bene- 
fii in foslerir^g quality ajul i>roducti^ity in product devel- 
opment. The formal process is stmclured ;md requires 
documentation and accountabihty. Tliese attributes make 
it easy to measure and improve the process. From our 
experience with infonnal inspections, iT is not clear 
whether the process t)rov4dcs imy benefits. Iloweven as 
an aid to improving the quality of the implemented code, 
it is worth fitrtlier in%'estigation. 
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6 Component Monitoring System 

Chrtstoph Westertetcher 

Cffris Westerteicher was the 
project mansger for the HP 
Component Mori ito ring Sys- 
* '^ -^S^^H tem comp u ter m Dd u I e a nd 
displays. As a result Dth<s 
team's efforts, production of 
the HP Component Monitor- 
inc) System has been auto- 
mated and streamhned to a 
maior extent With parts standafdjiation. onfy 300 
pans are needed far the entfre system. Chris jotned 
HP's Bdblingen Medicsi Division in 1960, shortly after 
earning a diploma in electrical engmeering from the 
University' of Stuttgart. He became an R&D designer 
of dispfays and interface cards for HP medical moni- 
tors, and IS currently a praject manager for anesthe- 
sia infarmatJon systems. Chris is the aiitfior of a tech- 
nical artfde on IC design prodyctivity and is a 
member of the VDE. 8nrn in Stuttgart, he lives m 
Leonberg, is married, has a daughter, and enjoys 
switnmmg, gardening, and traveling. 





10 Hardware Architecture 



Werner £. Heim 

R&D engineer Werner Heiin 

joined HP's Boblingen Medi- 
cal Division in 1986, soon 
after earning his electronics 
engm Bering diploma from 
the University of Braunsch- 
weig in Germany. He devel- 
oped computer module hard- 
ware, includmg the 
backplane. CPU. utility CPU, and EPROM, as well as 
the utility CPU firmware for the HP Component Moni- 
toring System Born in Gtessen-Hessen, Germany, 
Werner lives in Herrenherg, Baden-WiJrttemberg, and 
enjoys music and books. 

Christo ph We ste rte i die r 

Author's biography appears elsewhere in this section 

13 Software Architecture 



Martin Reiche 

Project leader Martin Reiche 
was responsible for the fun- 
damental design of the soft- 
ware architecture, operating 
system and development 
environment, and patient 
srgnal process mg software 
for the HP Component Mani- 
tGring System His team's 
efforts resulted in automation of all external activities 
and a smooth integration of each module into the 
monitoring system. This produced enhanced product 
reliability and effictency. After joining MPs Boblingen 
Medical Division in 1382. he developed EGG and re- 
spiratory signal process ing fnr the HP 78832 and 
78833 neonatal patient monitors. Martin received his 
electrical engineering diploma in 13B1 Irom ttie Um- 
versity of Wuppertal Born in Wuppertal near Co- 
fogne, Germany, he lives in Gaufelden, is married and 
has one child. He enjoys bicycling, music, and natural 
and life sciences, especially psychology. 

19 Parameter Module Interface 



Winfried Kaiser 

Win fried Kaiser was the 

project leader and designer 
for the parameter module 
tnterface^ front-end firm- 
ware, module rack, and 
some of the parameter mod- 
ules for the HP Component 
Mom ton ng System His ef- 
forts resulted m a front-end 
link that provides fast response, optimum use of 
available bandwfdth, configuration detection, and 
synchronization for a wide variety of modules After 
earning his engineermg dipfoma in 1982 from the 
University of Karlsruhe, Winfried joined HP's B&blin- 
gen Medical Division in 198Z He has developed hard- 
ware and firmware and been a project leader for sev- 






eral patient monitoring systems, and is now a project 
manager for patient monitoring products and en- 
hancements Born in Lahr in the Black Forest, Win- 
fried lives in Boblingen, is married, has one son, and 
enjoys traveling, swimming, and family activities. 

21 IVteasuring the £CG Signal 



Wolfgang Orossbach 

Hardware H8iD engineer 
Wolfgang Grossbach de- 
signed and developed the 
ECG/respirationHPMIDQIA 
and M10D2A modules and 
mixed analog-digital applica- 
oon-specif ic integrated cir- 
( cuits (ASIC] for the HP Com- 
ponent Monitoring System 
The modules and circuits produced significant reduc- 
tions in cost, power consumption, size, and compo- 
nent count Wolfgang joined HP's Boblingen Medical 
Division m 1985. shortly after receiving his elecironic 
engmeering diploma from the University of Stuttgart. 
8om m Salzburg^ Austria, Wolfgang lives m Murr, 
Germany. He is married, has two daughters, and en- 
joys jogging, bicycling, photography, and reading. 

25 Blood Pressure Module 



Rainer Roitietsch 

Mechanical design engineer 

Rarner Rometsch developed 
the pump assembly for the 
noninvasive blood pressure 
module and plastic parts for 
the display front assembly in 
the HP Component Monitar- 
. mg System The result of his 
' " *' efforts IE one of the smallest 
self-contained nonirvvasive blood pressure modules in 
the world — a unit that can be built in about two min- 
uies Rainer joined the RSiD unit at HP's Medical 
Products Group Europe in 198B, and l? now working 
on respiratory gas measurement He is named as an 
inventor in a patent ort noninvasive blood pressure 
measurement. He received an engmeering diploma in 
1386 from the Engineering School of Furtwangen. 
Born m Muhlheim/Donau (Ba den- Wiirttem berg}, Rain- 
er lives in Wildberg in the Black Forest He is married, 
has two children, and enjoys working on his house 
and garden and restormg old BMW motorcycles. 

26 Stripcfiart Recorder 



LesJie Bank 

Project manager Les Bank 
helped develop the twO' 
cliannel stripchart recorder 
^ f for the HP Component Moni- 
torrng System The efforts of 
his team resulted in a break- 
through in reducing the size, 
cost, and power con sump- 
hm of monitoring recorders. 
Les. a member of the fEEE, earned a BS degree m 
eEectrical engineermg in 1963 from the City College of 
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f^tew York and an MS riegr^ m elartrcat engineering 
in 1 973 from Nofttieastefn Universrty He lOJned HP's 
Waltham dmm m 1973 as a prodijeticm engineer. 
wofkif>| on pstient monitoring ^ysiHTis Befofe join- 
ing HR Les ^ivas a design eigmeef witii Hayir^on Cto 
Bom in Mew York City, he lives in Framin^m. Mas- 
s^^useits, is mam^, and fias two children 



29 Human Interface 



Gerhard Tlvig 

Gerhard Tivtg was the proj- 
ect leader for devetDprnent 
of the human interface fpr 
the HP Component Monitar- 
ing System He also devel- 
oped software for the alarm 
__^^^^^gmi~ manager and localisation 
il^B^B^&^5^ 1 00 3 s ttrat a ;1 1 o w efficient 
^■Fi^th -M £ gen Ef at ion of local Janguage 
versions so tt\e moniior can be used worldwide. Gef • 
hard joined HP's Bohlingen Medical Division m 1980. 
where he researched and developed display software 
and invasive pressure parameters for HP mDmtonng 
systems He feceiverl an engineenng dipioma in 1975 
from the Tech meal University in Bucharest, Romania, 
and later worked for two vears as a system program- 
mer for bedside mnnitor solTware systems at Mennen 
Medical Center in Israel He is named an mventor m a 
European patent for the Component Monitoring Sys- 
tem's human interface. Born in Bucharest, Gerhard 
Jives in Bdblingen, He is married, has two daughters, 
and enjoys family activities and traveling 



Wilhelm Meier 

Wtlhelm Meier was the de- 
sign engirmer responijible for 
ihe U? CompanerK Monitor- 
ing System's liuman inter- 
face design, simulation, and 
irnplementatEOn He de- 
signed an intuitive, easy-to- 
use consistent control sys- 
tem for all sp plication sand 
all members of the HP Component Monitoring System 
family He pined HP's BSblmgen Medical Division in 
1982 and developed human interface software for the 
HP7B353. 78B31 and 7B352 medical morjitors, gam- 
ing experience in human factors and human interface 
design He is named an invemor in a European patent 
for the Component Monitoring System human inter- 
face. He IS now responsible for improvements and 
enhancements to the Component Monfioring System 
human interface software. Wilhefm earned an electri- 
cal engineering diploma from the Technical University 
of Hannover in 13B1. Born in Obernkirchen in Lower 
Saxony, he lives in HeTrenberg, Baden -WLirttem berg, 
is married, and has two ctiildren, 



37 Giobalization 

Serhard Tivrg 

Author's biography appears elsewhere in this section 




40 Physioiogical Calculation 



Steven J. Weisner 

^^g^^ As the software project lead- 

^^^^^k ^ fof ^*^ management of 
■ J m^ HP Campcment Monitor- 

B4? '^ rStem teds^de momtof. 

J ^% ''■ '- Weisner was respon- 

^^. Si b le tar the system's exter- 

^^^L^^f^^^ rial spec if icatitjns and ctjn- 
^^^^^^i^^H tributed to softv^re 
^^^^^^^^^^ development His team s 
efforts resulied m a phystological calculation applica- 
tion that reduces the large amount of raw vital- signs 
data into derived values the clinician uses to assess a 
patient s condition. He joined HP's Waltham Division 
in 19B2 and has worked as a project leader for the HP 
central station and as a software engineer for the HP 
an-hydimia monitoring system. SON interface, and 
patient data management systems His prolessional 
specialties include human interface design and clini- 
cal information management. Steve is now a soft- 
ware project leader for HP cardiac care systems, re- 
sponsible lor external specifications and user 
interface design Before joinmg HP, he was a soft- 
ware engineer with Cornell University. He received a 
BA degree in 1976 in biology from Cornell University, 
and an MS degree in 1981 in biomedEi:::al engineering 
from the Un^veTSity of Wisconsin. A member of the 
IEEE, he is the author of technttal articles in the IEEE 
Transections on Biomedical Engineering and in the 
Proceedings of ttie Human Factors Society. Born in 
Paterson, New Jersey, he lives in Lexington. Massa- 
chusetts, fias a daughter, and enjoys bicycling and 
sailing, 



Paul Johnson 

Paul Johnson, a software 
development engmeer 
whose professional interests 
-?% .:igi i f >cl ude rea l-t t me op eratmg 
i£ iff systems, implemented the 
**^^L J hemodynamic, oxygenation, 
'^^ M/f and ventilation physiologic 
^% ^^ calculation displays and for- 

mulas for cafculating the 
displayed values for the HP Component Monitoring 
System These calculated values are good predictors 
of rr^ajor malfunctions or mortality in intensive care 
patients. Paul joined HP's Waltfiam Division in 1978 
after receiving a BSEE degree m 1968 from Purdue 
University and an MSCP degree in 1996 trom the Uni- 
versity of Lowell in Massachusetts He was a soft- 
ware engineer for HP's computer-aided manufactunrtg 
deparfmenl, a production engineering manager, and a 
development engineer in R&D Before joining HR he 
was a development engineer with the Medical Divi- 
sion of American Optical Co. and a hardware engi- 
neer with Raytheon Corp. A six-year U.S. Navy veter- 
aa Paul was born in Elkharf. Indiana, and lives in 
Groton, Massachusetts. He is married, has two chil- 
dren, and enjoys playing golf and listening to jazz 





44 Mechanical implementation 



ICarf Daumuller 

Karl Daumailiei was the me- 
ctianical design project lead- 
er for tf^ computer modijle, 
displays, and mountir^g hard- 
ware for the HP Camporient 
Momtofing System He 
helpffil reduce ttie number of 
parts dramatically over pre- 
vious patient monrtoring 
designs. After joining HP's Bdblingen Calculator Divi- 
sion in 137B, he sensed for two years as a process 
and production engineer for desktop computers and 
peripheral products Karl v^crked as a mechanical 
design engineer for over e^ght years at HP's Bdblin- 
gen Medical Division, developing the HP 7835x family 
of panent monitors. HP 9040 and 8041 cardiotoco- 
graphs. and mounting hardware for hospital installa- 
tions. Mow the virtual source engineering manager 
for the Boblingen Manufacturing Operation, he is re- 
sponsible for centralized sourcing of sheet metal and 
cabinet parts for all German manufacturing divisions. 
Karl received an engineering diploma from the Engi- 
neering School of Esslingen in 1979, Bom in Stuttgart 
in Baden-Wiirftemberg, he lives in Filderstadt, is mar- 
ried, has four children, and enjoys family and church 
activities and gardening. 

Erwin Rachslander 

Mechantcal engineer Erwin 
Rachslander was responsi- 
ble for the mechanical de- 
sign of parameter modules 
for the HP Component Mont- 
tnring System, He helped 
^^^^^ nt-j s i g n an enc 1 OS uf B that ca n 
J^ fl^^^^r '^^' assembled and serviced 
W" V^^^V without any tool Erwm 
joined the BSD division of HP's Bdblingen Medical 
Division in 19B5, shortly after receiving his mechani- 
cal engineering diploma from the Engineering School 
of Ulm At HP. he has worked on a TC^pD^/CO? call- 
bratof system. He is named as an inventor in a patent 
on a connector for the blood pressure mnnitor. Before 
joining HP, Erwm was a mechanic in msnufacturing 
and production at two different companies. Born in 
Kempten. Bavaria, he lives in Boblmgen, is married, 
has two children, and enjoys motorbikmg, photogra- 
phy, and playing a music syothesizer 

49 Automated Test Enviornmeiit 



Dieter Goring 

^^■^^ Software quality engineering 

^^^^^^ manager Dieter Goring de- 

m~ ^^^t veloped fhe automated soft- 

-H^lf the HP Component Monitor- 
"■'^BV ing System He designed the 
^"^4^ AUTOTEST tool and devel- 

^ oped a suite of structured 

tests, which runs 60 hours of 
automatic tests and 45 hours of semiautomatic tests 
overnight and weekends- Dteter received his engi- 
neering diploma from the Engmeering School of Furt- 
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wangen in 1967. After jorning HP's Compuief Systems 
DSvision in BdbJingen, Germany in 1973. he served 3s 
an R&D engineer, project engineer tar automated test 
systems, communications and office automation man- 
ager and information technology manager. Before 
joining HR he was an applicaTion programmer and a 
software project engineer. Born in DQsseldorf, he 
lives in Boblingen, is married, has two children, and 
enjoys sports, music, reading, and traveJing. 

52 Productmn and Final Test 



Otto Schuster 

^^■1^^ Production engmeer Otto 

^^^^ ^fc Schuster was respnnsibfe for 
I jP the productioji process de- 

' ^1^ ^m^ velopment and design for 
* manufacturing al the HP 

Component Monitoring Sys- 
i \-^gr \ tem. He helped ensure the 
iff' '^9^n concurrent design of the 
^ '^ ' product end Jts production 

processes — the first HP product desfgned in surface- 
mount technology in the Bdblmgen technology center. 
Otto joined HP's Bohlingen Medical Divistan in 1379, 
shortly after receiving an engineering diploma in elec- 
trical engmeenng from the Engineering School of 
Esslingen He served as a production engineer tor the 
HP 7B352, 78353, and 78354 monnonngVystems A 
resident of Heimsheim in Baden-Wuritemberg, wliere 
he was born, Dtto is married, has two sons, and en- 
joys skiing, bfcycling, and gardening. 

Joachim WeMer 

Pfoduction engineer Joachim 
Weller was responsible for 
die design and development 
of front-end production test 
systems for the HP Compo- 
nent Monitoring System and 
fo? HP-UX tools for statfstical 
process control He also 
worked closely with R&n on 
design testability and helped reduce manufacturing 
cycle time on the monitonng system After joining 
HP's Bablingen Medical Division in 1964, he was re- 
sponsible for the production of patient monitors and 
the development of a new generation of fmal test 
systems for the HP 78352. 7B354, and 783B6 patsenl 
monitoring systems. Joacharo receJved ao engineering 
diploma in 1984 from The Engmeenng School m Ess- 
lingen. Born m Stuttgart in Baden-WiJrttemberg, he 
lives m Herrenberg, is married, has two children, and 
en|oys amateur radio, windsurfing, camping, and 
stodving foreign languages 
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William T.Ward 



Jack Ward soir^ed HP's Wal- 
tham DEvisionin 1382 end 
has worked on the software 
and firmware development 
of crttical care bedside moot - 
tors, a r rhythm ta analyses 
systems, and medical data- 
base systems. As tfie man- 
ager of software quality en- 




gineering. Jack is now responsible for testing each of 
these prodticis for use in medical environments. He 
earned a BS degree in linguistics in 1372 from the 
University of Illinois and an MS degree in computer 
science in 1984 from Boston University Before joining 
HP. he worked as a software support engineer for 
Data General Corp The author of several articles pub- 
lished in technical journals, Jack teaches undergradu- 
ate and graduate courses in C, C-k, and software 
quality at Boston University Born m Wmona, Missis- 
sippi, he lives jn Brookline. Massachusetts, is mar- 
ned. has three chtldren, and enjoys music, gardening, 
and logging. 

58 Code Inspections 



Frank W. Btakely 

Client/server computing and 
software Quality improve- 
ment are the professional 
interests of Frank Blakely. a 
software engineer at HP's 
Appti cations Support Divi- 
sion FranK loined HP's In- 
formation Resources Opera - 
tmn in 1980. He helped 
develop a code mspGction process tool for HP's Data 
Management Systems Division that is now used early 
jn the software development cycle to help improve 
the tjuality of software products and the productivity 
of development engineers at hjs divJSson. Before jam- 
ing HR Frank was an MIS programmer at LooArt 
Press, Inc and a programmer/analyst with Informa- 
tion Resources Ltd. hie is a graduate of Colorado Cot 
lege, earning a BA degree in mathematics in 1973. 
and a gratJuate of the Universitv of Oregon wsth an 
MS degree in matfiematics in 1977. Frank is named 
as an inventor in a patent pending on HP cooperative 
services Born in Colorado Spririgs, Colorado, Frank 
fives in Roseville, Caltfornia, is married, and enjoys 
cross-country skiing, hiking, playing board rjames, and 
pafticipatmg in the Piacer County Fair Association. 

Mark £. Boles 

gA ^^^ A software qua hty engineer 

wP^^jflP^ fli ' "^ ^^^ ^^^ ' ' ^^^^^^^ S u ppo rt 
Division, Mark Boles is re- 
sponsible for metrics collec- 
tion, process improvement, 
and implementing processes 
and new methodologies for 
software development. He 
helped develop a code w\- 
spection process model for HP's Data Management 
Systems Division that is now used early in the soft- 
ware development cycle to hefp improve tfie quality 
of sflfiware products and the productivity of develop- 
ment engineers at h^s tiivision. Mark jorned HP's Com- 
puter Systems Division in 1 982. shorily after earning 
a BSEE degree from San Jose State University. He 
became a hardware reliability engineer for environ- 
mental and reliabihty testing for the HP 300Q comput- 
er and process improvements, and latet a software 
quality engineer responsible for test and prioductivity 
tools. Client-server application iniegratmn is hts pro- 
fessional interest. Mark is a member of the American 
Society of Qoality Control Born \w National City, 
California, he lives in Boseville, is married, and enjoys 
car restoration, snow and water skiing, and h "ir^'-^'i 
electric trains with his three-yeat-old son 





69 HP Vectra 486 PC 



Larry Shintaku 

Project manager Lany Shin- 
taku and his team developed 
the HP Veotre 486 PC acces- 
sories. Thesr new develop- 
ment processes helped HP 
^^ market the f i rs t persa na I 

"fkSK computer to use the Intel486 

'"^7 mfcroprocessor with an EISA 

bus, Larry jomed HP's Data 
Terminals Division m February, 1980, two months af- 
ter recesvjng a BS degree in electrjcal engineering 
from Fresno State College in California. As a hard- 
ware designer, he developed the HP 2623 A/2 termi- 
nal graphics subsystem, and later, as a project man- 
ager, he helped develop the e?tpanded memory card 
for the HP 1 50 Touchscreen PC. Larry is now manag- 
ing the development of the next generation of HP 
Vectra 486 PC products. Before joinmg HP, he worked 
in digital communications with Dantei Inc. A member 
of the IEEE, Larry was born in Fresno and lives m 
Union City. He enjoys racquetball. low-budget motion 
pictures, and Softball. 
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Mtchaet B. Raynham 



\ 




Exploring the creative links 
betv^een art and technology 
:'.ie among the professional 
MiBTestu of Mike Raynfiam, 
::n R&D development engi- 
1 aer at HP's California Per- 
sonal Computer Division. 
Mike helped design the HP 
Vectra 486 PC and its Ex- 
tended Industry Standard Architecture (EISA) connec- 
tor He helped achieve an extremely fast development 
cycle of six months from initial concept to production 
of the first EISA connectors, which allow EISA amd 
ISA I/O cards to be handled in the same cortnector 
Mike also worked on hardware development for the 
HP 21 16B, 2100A, and 3000 computers, the HP 
2B44A, Z645.A. ZB4BA. ZS47A, and 2703A terminals, 
and the HP 1 50 TouchScreen II, HP Vectra BS 16/20., 
and HP Vectra 486 persanal computers Before pining 
HP m 1 963 in Bedford, England,, he worked as a film 
recording engineer with the Bntish Broadcasting Cor- 
poration and as an apprentice with British Aerospace. 
He is .named as an inventor m patents or patents 
pending for a display paneL digital encoding/decod- 
ing techniques. DRAM on-chip error correction, low- 
cost connectors, and IC surface-mount process defect 
detection designs Mike is a member of the IEEE and 
acted as cha^r of the Desktop Fuiurebus+ sulKomm it- 
tee. He earned an H.,N.C. degree m 19B2 from Luton 
College of Technology and an MS degree in 1971 
from Santa Clara Universny. both in electrical engi- 
neenng. Born in Wrnnersh, England, he fives in the 
Santa Cruz mountains in Califonua. is married, and 
has two sons. He enjoys clay sculpture, ceramic tile 
painting, and watercolor paintmg 
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Oouglas M. Thorn 
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devetopmert cycle of six TnDf#(S ham \ms\ concspt 
to pfodi£tj&n d The ftrsi 0SA connectors, which al- 
Icrw EISA ami ISA 1/0 cards m be handled in the same 

cofwectar He joined HPs Opioelecironics Division in 
1980, and is now lisrad as an inventor on a patent on 

fiber optiC component design and an inventor on a 
patent pending on the EISA connector Before joining 

HP he was a consumer product designer wih Nation- 
al SemJconducior Corp and Fairchild Semtcondudor. 
He earned BS degrees rn 1975 m electrical and me- 
Chan ice I engineering from die University of California 
at Oavis. Barn in San Mateo, California, Doug lives in 
WDOdSfde, Calitomia, is married, and has a son. He 
enjoys sailing, carpentry, arcl^itecture, cooking, and 
gardening. 
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Marilyn J. Lang 

Maiijyn Lang joined HP's 
California Personal Comput- 
er Division in 1981 and 
f^ ^\. worked on IC test vector 
Y^*; y^ i generation and simulation 
for the HP 150 Video control- 
ler ASIC She also designed 
"leHP-HIL port extender 
"^ .I'-.ed in the HP Vectra f^S/lB, 
RS/20 cjnd ES/12 PCs. Marilyn then worked on 
memory subsystem analysis and design for the HP 
yectfa 386 PC. wh^ch led to he? wo^k on the memory 
coniroHer ASIC design for the HP Vectra 485 PC. Her 
efforts helped produce a high-performance, burst- 
mode capabiiitv that enhanced the competitiuo pnce/ 
performance of the HP VectrE] 486 PC Marilyn earnid 
a iS ctegree in 1975 in chemistry from the Sojthern 
Illinois University at Garbondale, an MS degree in 
biochemistry in 1979 froni the Univer^iw of Illinois at 
Urijana. where she also studied c;ompLiter science, 
and an MSCSE degree in 1908 in computer science 
and engineering from Santa Clara University Born in 
Chicago, Illinois, Marilyn lives in Milpitas, Cahfornia. 
IS married, has a daughter, and enjoys gardemng, 
science fiction/fantasy, and classical music. She is a 
member of The National Gardening Association and 
various huimne and wildlife socieiies 
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Gary W. lum 

Project manager Gary Lum, 
whose professional spec la l- 
rjes include memory technol- 
ogy and design, was respon- 
sible for developing the HP 
VBCtra 486 memorv control- 
lar and menwy subsystem 
.^^ _ architecture. His efforts re- 
^^^'^^ suited in a high-performance 
burst-mode memory capabiCity that helped enhance 
the competitive price/performance advantage of HP's 





V^ta^. 



25-MHz system Gary loir^ed HP's Data Tertninafs Divi- 
sion m 1 979 and \W3rked as a [ffojec! m-ansg^ for HP 
Vectra PC accessory cards, on the HP Vectra K and 
HP V^tfa ES PC, and on tC design for the HP 1 50 
TouchScreeo II PC. A member of tf^ IEEE, Gary was 

-.'.r-: ,1^ Q„5 3r,,c.jz ^'fi,., Vof^^ [h^ ]f\ QipeitinO. 

enjoys film and film history. 
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Thomas Tom 

R8cD software engineer 
Thomas Tom ioined HP's 
California Persona! Comput- 
er Divisron in l9B9andde- 

rveloped die firmware for 
security features arid the 
-— i fcZ_ / >^icro- DIN mouse support for 

iM^^ the HP Vectra 4^6 Basic I/O 
^"^^^■^ system (BiOS) He is now 

utfi,igiiing surtware to support features of HP's new- 
est PCs. Thomas is a 1993 graduate of trie California 
Polytechnic State University at San Luis Obispo with 
a degree m electrical engineering. Before joining HP. 
he developed real-time satellite simulation software 
for Stanford Telecommunications. Inc., and developed 
test software to evaluate integrated ciicuits at NEC 
Corp. Thomas lives in San Francisco, where he was 
bom. and enjoys basketball, tennis, bowling, and bik- 
ing. 



Irvin R. Jones, Jr 

Computer and system archi- 
tecture and artificial intelli- 
gence are the professional 
interests of [rvm Jones, a 
softwi^ra engineer who 
helped develop the HP Vec- 
tra 486/2ST system BIOS 
His efforts helped ensure 
that the HP Vectra 4B6 PC 
makes tlie most efficient use of its iniel4BG micropro- 
cessor. the EISA bus, and new memory subsystem 
Since joining HP's Califorma Personal Computer Divi- 
sion in 19B8, Irvin also helped design ihe system 
BIDS and system utilities disk tor the HP Vectra 
LS/12. the HP Vectra 4e6/33T PC. and the HP Vectra 
386 PC, Before [oining HP frvin worked as a digital 
designer on photocopier function cards for IBM, on 
the microcontroller design of professronal video sys- 
terns for Sony Corporation, and on a parallel comput- 
er pen ph era I interface for Bell Common teat ions Re- 
search. A member of the IEEE and the Triathlon 
Federation, I rvrn is named as an inventor of two pat- 
ents pending for HP's PC BIDS. He earned a SS de- 
gree in electrical engineermg from Stanford Universi- 
ty in 1 982. an MS degree in computer engineering in 
1986 and an MS degree in computer science in 1988 
from the University nf California at Santa Barbara 
Born in Dayton, Ohio, he lives in San Jose. California, 
and enioys triathlon competition, playing jazi on the 
vibraphone and drums, and collecting comic books. 



Christophe Grosthor 
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fleal'ttme tsw4evel softwafi 
design and apphcaiion de- 
v^l&pment are the prof es* 
sionai specialities of Chrts- 
tophe Grostt^or He prnfid 
HFs Grenoble Personal Dan- 



W 




Vectra 486 PC BIOS am. J 

BIOS He helped ensyr^ i:iaL m:, n^ 'ii^J-a ^db PC 
myites the best use of its fntel486 microprocessor, the 
EISA bus, and a new memory subsystem He recetved 
an MS degree m electronics from the Umvefsity of 
Toulouse. France, in 19B6 and a software engineering 
degree from Ecole Nationale Superieure des Telecom- 
inunuicai^QOS de Bretagne m 1988 Before joining U?, 
Chnstophe worked on object-oriented compiler de- 
sign as a software engineej' for Interactive Software 
Engineering. Inc m Santa Barbara, California Born m 
Strasbourg, France, he lives in Grenoble, is married, 
and ertjoys sports, mountain hiking, and traveling. 



Viswanathan S. Narayanan 

Software development engi- 
neer Sun Narayanan devel- 
oped the EISA initialization 
procedures for the HP Vectra 
4S6 PC BIOS- His efforts 
helped ensure that the HP 
Vectra 486 PC makes the 
best use of its Intel486 mi- 
croprocessor, the EISA bus, 
and a new memory subsystem After |oming HP's 
California Personal Computer Group in 198K. he de- 
veloped BIOS designs for the HP Vectra 386/25 PC, 
and IS now working on future HP personal computer 
products. Sun received a BS degree m 1980 from the 
Regional Engineering College in Warangal. India, and 
a\i MS degree in electrical engineering m 1985 from 
the University of Wyoming. Born m Secunrferabad, 
India, he lives in Fremont. California, is married, and 
enjoys gardening and plsymg basketball 



Philip Garcta 

1^^^^ 1 Phil Garcia was responsible 
m^^\M ^^r the EISA CMOS BIOS 
, ^^^^ ip interface and the cache con^ 
I f'WjlW^^ trol BIOS code. He has 
I ^'^^''" Ml% worked on kevboard micro- 
^"^ ^^^ * controller firmware design 

and PC utilities design for HP 
Vectra PCs, After joining HP's 
-*** ^ "^ Data Term i na 1 s Divi s ion in 

19B2 as a development erigineer he worked on ana- 
tog design for the HP 2700 color graphics workstation 
and the HP 150 Touchscreen PC, and on EMt/RFI com- 
pliance desrgn for the HP 150 and HP Vectra PC, A 
Stanford University graduate, he received a BAS de- 
gree m economics and electrical engineermg in 1 979, 
and an MSEE degree m analog IC design in 1 981 , Phil 
is named as an inventor m two pendmg patents on PC 
BIOS designs. Born in New York City, he lives in Sara- 
toga, California, is marnefJ, and enjoys hiking, skiing, 
old movies, and museums 
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Jofin D. Graf 

^^^^^ Development engineer John 

JHj^^L^ Graf joined HP's Cal Ifarnia 
^^^™^| Persons j Coniputer Division 
^ ^ T^ in 1 389. righi after earning a 
.^^^ i BS degree in electrical engi- 

^ ^^^ , neeri ng from R ic e Un ive rs i [y 
__ l9|B He Lhen designed hardware 

wKt^^ ' toofs to measure the perfor- 
• *'* — mance of existing PCs, and 
developed mathematical and sgftware modefs to 
evaluate and predict ttie performance oJ future archi- 
tectures These performance tools were used to de- 
sign and enhance the performance of the HP Vectra 
4B6 PC arrd the HP Vectra 486/33T PC John's profes- 
sional interests are focused on evaluating the perfor- 
mance characteristics of CPU, cache, memory, and 
video. Bom in Baton Rouge, Louisfaoa, he Itves m 
Sunnyvale, CaiifDrnia, is married, and enjoys Cajun 
conking, bodysurfing, and volunteer work in e ctiurch 
youth group 




David W. Blevins 

As a hardware development 
engineer at HP's Caiifornia 
Personal Computer Division. 
Dave Blevins developed the 
hardware for the backplane 
I/O monitor, a noninvasive 
tool that helps analyze a 
personal computers subsys- 
tem work load and prnvides 
data for predictive system modeling Dave, who 
jojned HP's Southern Sales Region m 1982 as a cus- 
tomer engineer in the New Orleans sales offEce, was 
3 member of the HP Vectra RS/20 development team, 
a CAE tools support engineer, and a hardware devel- 
opment engineer. He left HP in 1 990 to jam MINC, 
Inc. in Colarada Springs. Colorado, as an applications 
engineer. Dave received a BSEE degree in 1 982 from 
Washington State Unn-'ersjiy. Born in Middletown, 
Ohio, he Ifves in Calorado Springs, Colorado, and is 
married. Dave enjoys music synthesizers and comput- 
er music sequencing, high-performance motorcycies, 
mountarn bikmg. and playing guitar in a local jazz -fu- 
sion group. 




Cliristopher A. Bariholomew 

Chns Bartholomew jomed 

HP's Caiifomia Personal 
Computer Division in 1 983 
soon after earning BS de- 
grees in computer science 
and in electrical engineering 
from Te^as A&M University. 

0iA J^^^lk ^^ ^^ ^^ system perfor- 
A*^Kk ^mmS^ mance engrneer, Chris devel- 
oped the d<skJ/U, and BIOS performance modeling 
hardware and software tools tfiai help to noninva- 
sively analyze a personal computer's workload in 
these subsystems. These tools were first used to de- 
sign and enhance the performance of the HP Vectra 
486/25T PC and the HP Vedra 4B6/33T PC Chris' 
professjonai interests include embedded program- 
ming, object-onented programming, performance 
modeling, and muiiiprocessor architectures. He is a 
member of the IEEE and the IEEE Computer Society 
Before joining HP. he was a systems programmer at 
Compaq Computer Corp. Born in Jackson, Michigan, 
Chris lives m Fremont California, is married, and en- 
joys camping, radio-controiled airpiar^es. fishir^g, and 
racquettjaJI 
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The HP Vectra 486 Personal Computer 

The HP Vectra 486 series of computers uses the lnte!485™ microprocessor, 
a custom-designed burst-mode memory controllef, and the HP 
implementation of the Extended Industry Standard Architecture (EISA). 

by LaiT>' Shintaku 



The IIP Veclra 486 PC was the first of HP's new genera- 
tion of personal computers using llie Intel IBfi micropro- 
cessor and the EISA (Emended Industry Standard Archi- 
tecture) bus architecture. The Intel4SG is a high-perfor- 
niaJice microprocessor that integrates the CPLl 8K bytes 
of cache, mul a math coprocessor onto one chip iiinning 
at a clock speed of 25 or 33 MHz * Tlie CPL' instruction 
set is optimized to execute instructions and move data in 
fewer clock cycles than its predecessor, the lntel386 mi- 
croprocessor. The BISA bus was defined by an industry 
consortium of whM\ HP is an active member. The EISA 
bus dettnition objectives w^ere to migrate tlie existing 
16-bit hidustrv^ Stantiard .Architecture (ISA) bus into a 
32-t>it l)us, improve the DIVL\ peifomiance, and provide 
support for [imltipie bus masters while malntainiiig l>ack- 
waids compatibility witli all existing ISA tjackijlane I/O 
cards. 

The HP Vectm 486 development, objective was to deliver 
these two new technologies to market quickly. We were 
preserUed with st^veral technicai and product developnu^nt 

*^mm{ releases of ihe HP Mmm 486 series ioclucte the Vectra 4S6/2ST and VectrW33T, 
the 3alt0f uses 1h^ 33-MHi <j&rs\m of the Irttal486 micraprocesspr. 



diallenges in trying to meet this objective. These chal- 
lenges included: 

• Debning a physical bus connector that would acconmio- 
date both EISA ami ISA cards (see article on page 73) 

• Int^orfjorating ail the new technical design features that 
EISA offers 

• Developing performance enhancements targeted for the 
memor>' and mass storage subsystems. 

System Overview 

The Vectra 48(> uses the existing upright floor package 
that is used by the HP Vectra RS series (see Pig 1). Its 
mass storage, power and feature options ntalched our 
customer requirements for high-end seivGT tind CAD appli- 
cations, Tlie form factors for tlie printed circuit boards, 
already defmed by the Vectra RS PC package, fixed tlie 
anion rU of logic each board could support ^ the logic de- 
sign and printed circuit board partitioning, and the func- 
tional, EMC, mid perfonTuiiice objectives. The functional 
objectives were met by parlitionmg tbe system compo- 
neius so thai follow-on EISA products could easily lever- 
age core components developed by the HP Vectra 486 




Fig. 1. Tlie HV Vectra 486 per- 
sonal ramp Liter. 
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team. The EMC objectives were met by minimizing, 
througi'i design j source radiation ancl hamioiiics caused by 
niisniatehed impedances. The design required that clock 
speeds up to fi6 MItc be distributed o%'er several printed 
circuit boar(is and coniiectoiis. Meeting the EMC objec- 
tives was vei"y important since they j^epresented a poten- 



tial delay in the schedule if reguiatory re<iuirenienrs were 
not met. The perfoiTiiaiice objectives were met through 
the development of an Lntei486 burst-mode memoi^ con- 
troller attd a lilgti-perfomiance hard disk subsystem. The 
hurst -mode nieniory- controller is described on page 78 
and the disk subsystem is discussed on tbis page. 



The HP Vectra 486 EISA SCSI Subsystem 



HPs advanced PC mass storage prodycts have conspstently provided customers 
with performance and conformance to industry standards The HP Vectra 486 PCs 
cantinue this tradition tiy providing a high-performance storage subsystem that is 
compatible with EISA and SCS.J-2 iSmall Computer System Jnterface) industry 
standards. 

The investigation of customer needs for the first EISA PC, the Vectra 486, revealed 
that the highest-performance PCs v^/e^e entering new application areas. Customer 
and applicatjon requirements resembled more those of the works latron of mini- 
computet user ttian those of an indfvidual running a word processing apphr;atian 
Demanding compatibflity with the IBM PC AX cysromejs also insisted upon high 
capacity perfonnance, and reliability for such applications as PC CAD, multiuser 
UI^IX* operatmg systems, and multtclienL tile servers, 

HFz CaJifornia PC Division's (CPCD) advanced storage team responded by develop- 
ing, along with its invaluable partners at HP's Disk Memory Division iOMD}and 
Adaptec, a new ESDI i Enhanced Small Device Interface) disk famsly and Industry 
Standard Ardntecture (ISA) rfisk controller Each of [tie nev^ 2Q-Mbyte/s disk drives 
trom DMD provides up to 670 Mbytes of 16-ms average access time storage at an 
MTBF [mean time helween failures) of 150,0[)0 hours. Adaptec s controller not only 
supports the drives data rate, bul also provides a 64K-byte read-ahead cache By 
contmuing to read data past the user's request the controller s cache already has 
additional data the user is likely to want later, At its introduciiDn, the Vectra 48Bs 
storage subsystem pravidecf excellent performance, capacity, and rehebility while 
=staying PC- AT software compatible, 

The engineers at CPCD realized that although powerful for its ttme, the ISA disk 
subsystem's performance had approached its architectural limits. Further perfDrni- 
ance innprovemants could only come with fundamentar design changes. Unlike ISA 
^isk subsystems, a new architecture would take full advantage of the EISA 1/0 hus 
and other new technologies 

the hrst products based on tbis new architecture appeared with the mtraductmn 
of the Vectra 486/331 Targeting once again the multiuser UNIX operatmg system 
environment and Novell Netware file server customers, the advanced storage 
team brought to market the PC industry's first EISA SCSI -2 storage subsystem 
Contributors from all disciplines in the PC Industry supplied state-of-the-art cornpo- 
nents. Hardware suppliers developed the EISA SCSI host adapter and the 
440-Mbyie to 1 QOO-Mbyte SCSi'2 disk drive family while software suppliers 
created the industry's first tagged queuing SCSI-2 disk drivers fat the Santa Cru7 
Operation UMIX operating system and the Novell Netware network operating 
system 

Tagged command queuing is a feature of SCSU2 that allows a penpheral to intelli- 
gently execute I/O requests from the host computer The peripheral can, but does 
not have to, reorder the sequence of the I/O command :5tream to optimize Jts e^- 
ecution. By use of the queue tag. the peripheral can associate the I/O request with 
the data, thereby not requirmg that the data he associated with a single pending 

'UNIX js 3 U.S registered tiademark of Ul^lJC System LabotatDrse^ in the U.S.A. and Crther 
CQuntries 
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I/O request. Fig, 1 illustrates this concept. Five 3/0 requests are generated all at 
once in the sequence shown The peripherai device decides to reorder the re- 
quest j^ for optimal execution and gives the completed requests back to the host 
adapter m the optimal order. The host adapter associates the returned data with 
the correct tag, and reassembles the I/O thread originated by the system. 

From the 32-bit bus master host adapter, which supports up to It^Mbyte/s. single- 
ended fast SCSI, to the 12-ms access time caching disk drive, the hardware com- 
ponents represent some of the best of today's technology applied to the PC envi- 
ronment. However, choosing the highest-perfarmance components is only part of 
the development story Tuning each subsystem component for UNIX and Netware 
application performance made the Vectra 486/33T more than the sum of its parts. 
The team apt«mi7ed each of SCSl-2's performar^ce parameters and features while 
staymg within the industry standard Additional HP proprietary perfurrnance tumng 
o! the drive's l28K-byte cache further enhances system performaiice. 

Today's PC SCSI subsystem offering is just the beginning. The architecture can 
support a wide variety of SCSI peripherals available industry-wide. For ihe first 
time PC customers can have access to such diverse peripherals as CD -POM, tape, 
DAI and removable magnetooptical storage. In addition, ih^s EiSA SCSI architec- 
ture allows far system performance growth as the industry continues to develop 
SCS^2 to its full potential. The SCSI-2 storage subsystem architecture will meet 
the challenge of future customer needs for both added perfomiance and greater 
peripheral connectivity, 

Differentiating products that are based upon widely available industry standards is 
difficult. After all, an Intel486 microprocessor runs just as fast tor another PC 
vendor as it does for HP HP's strength lies no! only in its SPU architecture but also 
in lis ability to fulfill particular cus.tamer needs Every Vectra 4S6 and 48B/33T 
storage subsystem has been optimired to provide customers with the best per- 
formance and reliability in an EISA PC. 

Mike Jerbic 

Development Engineer 
CaJFfornia PC Division 
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The pliysiral |mrliti<iiiing n( logic (sw Fig. 2a) dividos the 
systt^m into fivi* prink-d rircnii boiird assemblies (^ei* Fig. 
2b). The cor^ assemblies consist of a motherboard con- 
taining fhe core EISA corUroI logic and local I/O Icj^ir, 
and two venical piirUcd tin-uil a.s*>Lniiblies coniaining the 
physical I/O comicciors Tor tlie kcybtjard, mouse, and 
three I/O potts: (wo serial atid one pai^allel. Thcsc^ cojx- 
assemldies can be U^veragefi for future EISA products. 
The remainitig two assemblit^s art^ the CVV atifl memory 
ptirUed cir'( nil hoard asserul)hes, Tlie Cl'l' Ijoard contains 
the lnlel48(5 iind related control logic, and tlic niemorv^ 
board contains the UP burstHno<le controller atitl SIMM 
(single in-lijie jnemory module) soc^kets for RAM memory 
upgrade. 



Product Development Overview 

Tlie uiue lo-maiki'i (ilijecnves for the HP Veclra 48(5 prod- 
uct requirtKi a new approach to thi^ tKinnal dev(Hoi)nient 
process used Tor past products. Managing three parallel 
h^chnologj' developmt^uls. the lntel48^\ Ihe KISA bus con- 
irolk^r chips, ami the ineiuorv i-ont roller, and keeping ihe 
project on an aj^ressive schedule was ilu^ main challenge 
for the HP Vectra 486 team. To add to the challenge, two 
of die Ihree critical technologies in development were 
outside HP (i.e., the IntelliStJ and ihe EISA bus eontrol- 
ler}. The fu-st step wa.s tcj outline die overall (hnelotmient 
approach that wovdci ineel the time-to-markel objectives 
widi a proditct that met our quality standards, Tlie devel- 
opment process also liad lo l>e Ocxible eno\igh lo Iraek 
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the parallel developmenl of the Intel486 processor and 
ihe EISA cMpscL The resulting development, approach 
consisted of two main phases of execution (see Fig, 3), 
Our traditional product development cycle required three 
to four phases. 

We felt we could combine the breadboard and the labora- 
tory prolotypc phases antl still nieel all Uie retiuiieiiienLs 
for detemiining fe^isibility, design for man u lac taring, de- 
sigrt for BMC. quality, and functional veriricatiou in the 
first phiise. This approach took less tinie imd cut out 
redundant or inefffctive processes. Al'ler making the nec- 
essary changes to the design in the first phase of the 
projt^ct, the second phase focused on getting the man- 
ufacturing process ready for volume protract ion and ex- 
ecuting produci qualification testing for HP environmen- 
tal^ regulatory, and quality requirements. 

The HP Vectra 486/33T 



Many processes were performed in parallel to reduce the 
amount of development time which, in many cases, in- 
cn?ased the risk of having to address dependency pnjb- 
lenis caused by something failing. Other imponaiU pro- 
cesses were put In place to address these potential 
development roadblocks. An example was the establish- 
meut of direct interactive technical conmiun I cation links 
with outside cornpiinies for technical reviews ami 
changes. Tliis liaison saved days or weeks of rlevelofiment 
time for the IIT Vectra 486 team- The team also made 
sure that contingency plans were made for the criticral 
processes such as printed circuit board layout, labritta- 
tion, prototyping, and the tools of development to ensure 
tliat progress would be maintained in most circumstances. 



During the latter stages af ihe HP Vectra 486/25T devefopment program, develop- 
ment of the Vectra 4B6/33T was initiated This system, designed artxjnd the new 
intel4B6 33-IWHz micro proc esse r, provides higher perfnrmance at a lower cost in 
LAW server, multiuser, and PC CAO applications By combinmg this pfocessor tech- 
noJogy with enhanced memory and mass storage subsystems and by buildmg on 
the achievements of the Vectra 486/25T, the Vectra 4&6/33T program was tirrven 
by three major objectives fast time to rnarket. high iierformance, and high quaJity. 
To meet the chsilenges ot these three objectives, the development team impiem- 
ented two key strategies: the first was focused system design understanding, and 
the second was ongoing process improvements. 

System Development 

A strategy of the HP Vectra 48B implementation was to partition the system com- 
ponents to provide easy leverage for follow-on E(SA products such as a 33-MHz 
system The areas of engineering and product reuse were the package and power 
system, three core printed circuit assemblies, and the video adapter card Through 
performance anaJysss of the Vectra 486/251 system, we were able to focus on the 
areas that woeld significantly contribute to our objectives, These areas included 
design for 33 MH^, the addition of a high-performance second-ieveJ cache, incly- 
sfon of both write and memory buffers, and integration of a new high-performance 
SCSI (Small Computer Systern Interface) hand disk subsystem. 

To achieve the required performance levels for the 3Z-UHi system, it was deter- 
mined that a second level cacfie (in addition to the on-chip Intei486 8K-byte cache | 
was necessary Simulations also showed that ssgnificant performance gams could 
be achieved through the addition of a bus write buffer and a metnory write buffer 
Therefore, the CPU design includes a IZBK-byte. Z-way set associative, write- 
through cache, with one level of bus write buffers. In addition, support for an 
optional Wietek 4157 floating-point coprocessor was added to further meet the 
needs of our customers requiring increased floating-point perfomiance for their PC 
CAD applications 



Further performance simulation and analysis showed that the capabilities of HP's 
custom burst-mode rrremory GontraNer, first implemented on the Vectra 48S/25T, 

would contmue to offer superior perloimance. with mi nor changes for optimising 
33-MHz operation and with the addition of a memory write buffer Therefore, the 
design of the memory controller was leveraged for use in this higher-performance 
system. In fact, the resutt of the redesign of the memory PCA is a memory board 
that can support both the Vectra 486/25T and 486/33X with optimal performance 
enhancements for both, 

Durmg the Vectra 48B,/33T design, the team was continuously looking for ways to 
improve the quality and manufacturability of the system A significant contribution 
to this goal was made on ihe CPU board by eliminating all discrete delay lines. 
This was achieved through the use of delay lines im pi erne rued by traces on the 
printed circuit board, Using simulation and an understanding of the physical prop- 
erties of the printed circuit board, the team was able to deliver delays with excel- 
lent characteristics and margins. This resulted m higher reliability, lower costs, and 
improved manufacturability. 

Process Development 

To achieve the fast tune to market, the team needed to apply the lessons learned 

from the efforts of the Vectra 486/Z5T program. In addition to using the improve- 
ments made for that program, several other enhancements were required. To 
ensure team focus, the team constantly reviewed their decisions against the well- 
communicated list of "musts" and "wants". Increased levels of simuEatton were 
used along with frequent design reviews l^ew and improved processes were 
irislituted for supporting the prototype systems used in test and verification and for 
trackmg and solving detects found durmg these phases. The result of all of these 
efforts was a very efficient system verification cycle leading to a timely rr^anufac- 
turmg release of a high -quality product. 

Mark Linsley 
Section Manager 
California PC Division 
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Conclusion 

The Vectra 486 de%^elopnieiit team was confronted with 
the rhalienge of bringing an Intel4S(>based product to 
market alniost simultaneously with the announcement of 
the Intel486 microprocessor. By using new (ievelopment 
processes, the HP Vectra 486 was the first computer on 
the market using the InteI4S6 CPU and the EISA bus. 
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Tlie EISA Connector 

Providing backward compatibilitv in the EISA connector hardware for ISA 
I/O boards resulted in a bi level connector design that provides pins for 
both bus standards in the same connecton 

by Michael B, Raytiham and Douglas M. Thorn 



One of the reasons for the rapid growth of the personal 
computer (PC) market is the wide variety of compatible 
software* and hardware peripherals available for these 
machines- This compatibility has been provided by a di?- 
facto industiy'-standard bus spccMOcation called Industry 
Standard Architecture (ISA). Altliough stalled with the 
original IBM PC system architecture, the standard has 
evolved lo where it can be adopted by any PC manufac- 
turer, tlms providing a slat>le platform for softwiire lUMi 
har(Jware development. 

The EISA (Extended Indusliy^ Stan<lard Architectiirt*) is a 
superset of the ISA 8-bit and U>-bit architecture. The im- 
I)tirtant features of the EISA specirication inc^hnle: 
Full compatiliilily with I he ISA standatd ISA HAnl arid 
16- bit expansion txtards cmi Ik* installcfl iti EISA slots. 



• Support, for a 32-bit address path and for 16-bit or 32-bit 
data transfers for CPU, DMA, and bus master devices. (A 
bus master is a device thai drives the address Imes and 
controls the signals for a bus cycle.) 

• An efftcient synchronous data transfer protocol 1 hat pro- 
vidcs for normal single transfers and the cycle control 
required to execute burst cycles up to 33 Mbjtes/s. 

• Autonmtic translation of bus cycles between EISA and 
ISA masters imd slaves. 

• Suppori for a bus master architecture designed for intelli- 
gent peripherals. With EiSA-based computers the bus 
controller can operate some of the lines on behalf of the 
bus master, 

• A centralized bus ari) it ration scheme that supports pre- 
emption of an active bus master or DMA devic:e. The 
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EISA arbitnjiion nirlhi>d grants access lo Iht* bus for 
DMA dtmcps. DRAM refresh, bus niLislers, and bus aiid 
CPU functions on a fain rolalional basis. 

• Ijevel-triggered, shareable interrupts. Edge-i riggered op- 
eration ensures compatibility with interrupt-dnven ISA 
devices. Level-iiiggered operation facilitates sharing of a 
single s^'^stem intemipt by a number of devices. 

• AuloiTialic ronfiguration of sysieni and expansion boards. 
EISA expansion l>oard man u fact urers provide ronligu ra- 
tion flies and product ideril ific:ation iMomiaiion st> that 
during system initialization Qiese boards can be autontati- 
caily configured into a system (see page 84). 

More detailed infomiatiou about the EISA bus can be 
found in rcferenc^es f 2 and ^1 

Engineers from flP's personal computer group were in- 
volved in detining the physical and electrical design of 
the I/O bus, the boaid connectors, and the logic control- 
hng bus timing for the EISA bus specification. Their most 
obvious rontnl)uiion was the "double-decker" EISA con- 
nector. This coiuieelor lias two levels of pins. The first 
level rnait\!ains ISA compatibility and die second level 
adds the pins for the EISA bus spc^cification. Tliis article 
will describe the EISA connector and some aspects of the 
development partnemhip tliat led lo the development of 
the connector and 1/0 caid luudware. 

Background 

The EISA connector was an important part of the imple- 
mentation of the EISA bus standard. At lite time we 
started this pniject there was no connector available tliat 
met the general electrical and mechanical clmraeteri sties 
required for EISA. Siime sohilions were proposed but 
tliey were discaixied liecausc^ tbey were not cotnjietitive in 
size and electrical perfonuance. The UiM Microclumnel* 
I) us iu'c hi lecture had already doubled the pitcli of con- 
tacts from 0.1(K)-incb to 0.()5()-inch centers on theii" con- 
nectors, and Lt was fell that iJie EISA solution must use 
this contact density txi Ije competitive. 

The technical responsibilities for the proposed EISA bus 
design w^ere dividt^d among a smaJI group of the origitial 
EISA consortium companies. The responsibilities for tJie 
defniition, development, and sourcmg for the EISA con- 
net tor were given to Hewlett-Packard and Compaq Com- 
puter Corp. 

Because the EISA connector was the first physical evi- 
dence of the EISA hardvi'tu'e. it became unpoitant from a 
public relations stiuidpouit that the design nol only be 
backward compatible with ISA, but also be perceived as 
technically superior (e.g., higher-perfbrmance, well de- 
signed, etc.). 

The availability of production connectors was a serious 
concent because once t)ie design was fmalized tlie poten- 
tial demand for connector hardware would be \^er>- high. 
To ensure that a highvohime supply would be available, 
and to manage the technical risks, ii was decided to re- 
cniit at least two major connector manufacturers to de- 
velop and produce the connector. HP and Compaq C Com- 
puter Corp. recniited Biimdy Corporation aud .AMP 

"Micfochanrsel is the bus architecture defueloped far the IBM Personal Sysi£m/2 compiiters 



Incorporated into the EISA consortium lo participate in 
the design. 

Organ isEaliDna] Challenges 

Tlie connectrjr prfjjeci was managed primarily by a joint 
team of HP and Coiupac] engineers representing the EISA 
consortium. The teatn attracted c^otmector tn an ufaci urea's 
vising the nnmber of customers within the consortimn to 
convince the ntanufaclurers of the magnitude of tlie busi- 
ness opportunity for EISA connectons. The prehminaiy 
design requirements were eslablisiied by MP and Compaq 
Computer Con>" as piul of the EISA 1 echnical specifica- 
tion. Tills technical specification, which was revised and 
published periodically by the consortium, was the single 
specification that all cormector vendors ys+*d to develop 
their specific connector designs. The periodic revision of 
the specification proved \eiy valuable in maximizing the 
collective technical contiibutions of the cotuiector ven- 
dors. All potential vendors could obtiiin a set of technical 
rtxiuirements by joining the EISA consortium. These ven- 
dors could also rCK'ommend technica] ideas for the design, 
which, if adopted, would become pari of tht^ specification. 
All tecluiical contril>ntif)ns incorf>orat(*d into the specifica- 
tion bec^uue the intellectual property of tlie consortium, 
and therefore, Ijecjune available to all members. This pro- 
cess protkiced a very robust and thorougli connector 
specification by using the collective efforts of all pattici- 
pants, some of whom were direct competitors. Rg. 1 
shows the design mid development iiifonuation fiow^ dur- 
uig this process. 

The connector's technical specification was a [>erfonn- 
ance-based specification. Except for iht^ fjasic mechanical 
diiuensions, all parameteis were specifieii basted <m elec- 
trical, environmental, mechanical, or process jjcr fori nance. 
Tills performance -based approacli allowed each vt^ntior to 
provide subtle but significant design features in their final 
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;lg^ 1. InforntatJon fltnv during the design mid tlevelopmi^nt of 
the EISA (.0111 let lor. Ml fonopctor manufacturers rt*cei\ed the 
EISA bus specification and provided feedback to the EISA 
connector architects without iiiterfat^ing to other nianufac tur- 
ers. Tliis provided the best possible tecluiical design nithoui 
Gonipronusing vendor confidentiality. 
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EISA Configuratioii Software 

Of\e of the sirecifcsriom erf tt« 0SA standanl detiTies ms process for configuring 
EISA slots mm a compyief system When the EISA COTsofHum W3S being formed, 
Comf^ CiJmptjir Corp, startBd the mm\ devekpnent of the software fof conf tg- 
uring BSA s^0IS So " ----- -^^ t,eggn. two HP engmeers weri assfg^ecJ 

to work with Compc "t effort 

l\m configuration software detects i*)e presence of sc^ssory ^rds inserted into 
the BSA slots of the computer aod provides a process to corrfigure the cards imo 
the system The cDnfigumiJon process begins wtth the configuration propam 
reading a configoratiDn file for each of the accessory cards installed in the EISA 
slots The configuration fi!e corrtains infofmation about the card that enables the 
program to determine the optimum settings for ar»y switches or jumpers on the 
card. Once the pri^ram has detefmmed the required configuration of the accessory 
cards, it idantrfies atry manual switch settings or changes that may be necessary. 
and mstnicts the user to make them The system configuration information fs ihsp 
written to nonvolatile memory where it is stored and available to the BIOS {Basic 
I/O System) each time the computer boots up. 

HP confributed heaviiy to the usability features of the corrfiguratian sohware by 
using a fully equfppetJ camera studio in our usability department to observe people 
using the configuration utility, 

Some of the testing showed tliat nonprocedural interfaces, such as a wmdows 
environment, didn't work in the insta Elation process as vvell as a procedural inter- 
face. {A procedural interface presents a series of steps — procedures — that guide 
the user A nonprocedural interface simultaneously presents a number of tasks 
from which the user must select the next step.) The initial version of the configura- 
tion utility used a windows-like interface. Tlie taier versions of the configuration 
utility were changed to use a procedural interface In addition, help screens have 
been improved, and some of the processes have been combined into a single task 
We also improved the code to make it run faster, eliminating a perception by some 
users that the system was hung up. 

The usability testing continues, and the latest version of the configuration soft- 
ware has a much improved user interface. This new interface is fully procedural, 
and tests have shown that even the most inexperienced users can effectively 
configure an HP Vectra computer 

More about the configuration files ami the EISA slot inttialization process can he 
found in the article on page B3, 

Tony Dowden 

Learning Products Engineer 

California PC Divisir;n 



connector design. This preserved a healthy comi>etlrivp 
envirnnment among \\\v connector vpnrifji'H and allfw^cd 
Uiem Lo mafkel Wwir individual IVafurcs antl ht^nrOlH. 

Customer and Vendor Relations 

The eKistt^iic*' of (lie cimsorlitini ])rovided the technsrai 
henefits ntentirmed above and ii also freed HW ('oinpii<i. 
and other ronsonitiiii nieinbers to establish the neeeasat'y 
f'ustomer iind vendor relationsbips that woidd eventually 
lie neeessaiy to nianufat'tttre j.>r<Kkit"ts. Nondisclosure 
agreement's wc^re establistied l>etween HP mid sevend 
connector manufactiirers. This allowed HP to negotiate 
supply eontractii and eharacierize tJieir business needs 
independently of any UP conipetilnrs. This providetl Ihc^ 
necessaty f>iisiHess and prorhict pkinning isolation be- 
tween HP and all other competitors. 

During the development proc^'ss it was a challenge to 
docimiettt and manage the flow of infonnaf iott between 
all parlies. Fig. 2 sbows how Ibis wils dom\ Eacb PC 
nianiifactuter wlis able to negotiate a supply of connec- 



tors without disclosing volume, pricing, or new product 
schedule to poteniiaJ competitors. There was no exchange 
of information between connector vendors, and each E*C 
vendor had independent access to the connector manufac- 
turers. 

EISA Connector Issues 

T\w key issues siuroimding the development of the EISA 
conne<:tor were niaintiiining ISA electrical and mechanical 
compatibility at a compel iiive cost, and excetlem market 
perception for the final product. 

Compatibility, The compatibility issue meant that (he exist- 
irtg ISA or PC AT boards had to be supported both elec- 
trically and mcnrhanically in the new scheme. The new 
scheme also had to supp<:jrt a new BISA board that used 
the EISA ;i2-bit burst mode bus. These constraints traused 
rejection of solutions that required: 
Increasing the height of the worldwide PC AT product 

* packages by (J.:3 inch 

Investigating how many PC AT plug-in cards worldwide 

* have components in tbe 1/S-inch space above the comiec- 
tfjf 

Adding the EISA expansion as a separate outrigger or 

* tattdent coimector. 

Electrical Performance. The additional EISA signal lines 
were speciOetl by the consortium, including power, 
ground, and spares. This meant adding approximately 90 
pins to those already preset)! on the ISA connector. Tlie 
way in wbicfi they were added was imponant because 
die goal was not only to provide for lite additional EISA 
pins, but also to improve the RF perfonuance of the ISA 
section to work with TTL bus logic bavitig tyjiiciil logic 
transition times of 2 ns. Improving RF iierfonnance itteant 
that tlic coniu'ctor impedance had lu inatth lite tyiiical 
mullihiyrr printed circuit board trace impedance^ of fiO 
ohms, and multiple-line switching crosstalk to a victim 
line hatl in be h>ss tlian 2(fX) at 2 ns,^ Oosslalk perfonn- 
am e is hu^gely deti^nuined by tbe ratio of the number of 
signal pins to tbe numljer ot^ groiitid pins mid the isokh 
tion provided by the EISA printed circuit board ground 
plane. Thcrerore, the BISA ctmnector had to have a lower 
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Fig. 2, Informrttiixi fluw.s lnHwr^eii PC njaniifatt.urfTs and 
[ uiiinntor riuiiuifjicturers. Thr^goal here wos to t?nforctc cDnO- 
denliaiity betwetn tlu> connpclor nmtmfactiirers and i^acli PC 
vejidor they worked witlu 
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Fig. 3- Ponif^jii^ of ESA nnd EISA exfjarision boards, sfinwin^ rtic 
1/0 pms oil each board imd a f-ntriway vtow of llii? EISA f oniipf irir 



signal-to-ground pin ratio tliaii aii ISA bus because the 
ISA and EISA signals togelher tbrrn a high-perfomiaiire 
bus, (irounfi i>laiTeH were assunie^l to he j)n:*sent in tiie 
iTioiherlioiird and B1SA prinred cin.nut boards, antl rhe 
curreni- capaciiy of tiie ISA contacts had to be 3A per 
contact for ISA power pin conipatiblity. 

Mechanical Performance and Markel Perception. A positive 
public perception wjls imiK)!lanl to the accept aiice of the 
new EISA standanl The connector desigii needed to 
main lain the reference features, seating planes, and inser- 
tion ft>rce (jf ISA lioards. Tliis was key if) Uie (i vera! I me- 
chajiical design Jind it also eonmiunicated ergon oniie 
back^vard (^onipalibilily to the us(t. For this reason li was 
decided that the EISA connector should Iiave the same 
dimensions as the ISA connector 

EISA Connector Solution 

The sotulion that met*ts all of the objectives is an exten- 
sion of tui idea used from the veiy tii^t scheme pro- 
posed—the double-decker (or bilevel) conitec^tor, Instea(i 
of adtling the EISA signals in froni (if, on the side of, or 
underneath (by Lncreasuig the height ) of Ihe ISA conne<^- 
lor, the aiidilional signals were added below the level of 
Ihe existing sigiud pins (see Figs. 3. 4, and 5). Incidental- 
ly^ this solution wiis arrived at simultaneously by IIP and 
Btimdy Coiporalion. 

A I IIP this solution evolved from mvestj gating how to add 
grounds to the ISA connector section for use with EISA 
cards. It was determined that the adtlilional grounfis 
could be located on a low^er level th^ui thf ISA contacts. 
Since the ground contacts had to be iis reliable i^ts the 
signal fontacls, the EISA signals w^ere also located on the 
lower li^vel (see Fig, 3). 






W 



m 
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Fig, 4.* (a) Cross-sectional \1ew of the npj>er-levci contact of the EISA ronnector (b) Cross- sectional vipw uf die lower-level eoniaci of the 
EISA connector, (c) Cross -set: tioiial view af both i:ant,act levels. 



76 Ortober 1991 H^wi^^Packard Jotmml 



)Copr. 1949-1998 Hewlett-Packard Co. 



EISA Access Key 




Fig, 5,* h^Hidt;- vfcw of uiie lialf 
of cira EISA connector. The EISA 
iKx'eifis key prt'VCTiis ISA boards 
Eroin being iriijt^rteil tcj the depth 
of the EISA contacts. 



Mhe pFClures ui the fiSA connecior seaians shuwn <n Frgs. 4 and S were tm^a frrain 
cofin^LofS manufactufed bv Burnriy Corporation 



Since this design allows EISA signals* (mciudlng grounds) 
in the* same ntotiierbomd spaci* as an ISA systeni and the 
connector remains die same height, the signal-Ui-grniind 
piji ratitJ UiV llie ISA signals is (^fTeclivrlv redu<etl to S:l. 
[niproved isolation lor rhe H:Si-M][y. BCLK (harkj>lane 
clock) is provicied by acljat^ent RF grounds. Two of the 
grounil pins are at BCLK so rJiat the gold finger pads are 
on opposite sides of live printed circnil board. Thus these 
pins can be direrily connected lo lite pliig-ir\ boajxi 
grotmd plane with a low-inductance eonnetiion. 

hi addition, the iiil<niial groiinci pkuies of tbe plug-in 
botird ttnder the golf! lingers, which play a key role in 
detcrtnining overall eorniector electrical perlbnnancc, can 
extend almost to tlip stnface of I Ik* molherhtjard. Tbese 
help provide electrical isolation between the two bakes 
of the connector, single-line crosstalk between a(|jacenl 
pins of o% to 7% at 1-ns edge trajisitlon times, and a con- 
trolled 55-<ihm to G5-oluT^ signal intfieckince.^ An added 
benefit ol the duaJIovel etmtact structure is that although 
tlte number of coiUacls doubled, the insertion force only 
increased from 28 pounds for the ISA connector to 35 
pouncb for the EISA connectoi. Tht* signal density of 
each level is the sjune as tlie ISA connectors (20 jier 
inch), thereby minimi ^^ing the impact on printed circuit 
boai"d rnanufacturing reguircmenls. 



Conclusion 

Tlirough a joint effort with other members of the EISA 
consojtium, we designed a connector that meels all the 
lechnkiil design R^quiremi^nts nect^ssary for industry^ ac- 
ceptJUTC^. Ciiven Ihc^ numljcr of companies a^id piuties 
involved, we achieved an extremely fa^t development 
cycle of six months from start, of this project to the pro- 
duction (jf the first connectors. 
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The HP Vectra 486 Memory Controller 

The memory subsystem architecture and the memory controller in the HP 
Vectra 486 personal computer provide b high-performance burst-mode 
capability. 

by Marilyn J, Lang and Gar>^ W, Lnm 



During the investigation phase for the HP Vectra 486 per- 
sonal computer, iri-house perfonriance tools coririrnied 
that the riieniory system was a key to overall system per- 
formance (see article on page 92). Selecting an optimal 
memory and controller architecture for a high-peifoiTn- 
ance memory^ subsysteni was a major design consider- 
ation for the IIP VectiTi 486 design team. 

White [>ertbnrjance wa>s c^oiisidered important to Llie suc- 
cess of die IIP Vectra 4S6, it was but one of many impor- 
tant factors to consider for the memory controller design. 
The PC server niarkcl (a target for the IIP Vectra 486) 
continues to demand more memory, yel entry level sys- 
tems require a small starling memory and incremental 
memorv' size. There is also an emerging need to simplify 
the in.stallaiion and contlguratifni <:)f memory t>y both ctis- 
tomers and dealei^s. We were also anticipating future hv 
teI4S() microprocessor speed upgractes, and wanted a 
memory' ai'cMtecture that could support these upgrades 
with minimal changes. And, of course, we were striving 
to deliver, at a competitive price, a system that, included 
the EISA standard. 

From these requirements, the memory controller objec- 
tives became the fiesire to: 
I Meet the HP Vectra 486 schedule and cost stnjcture 

* Provide competitive performance for 25-MHz systems 

* Have a large and logical memoty upgrade scheme 

t Provide^ a design for supporting higher-speed Vectra 486 
systems. 

With these objectives, tfie design team bej^an investigating 
relevant technologies that would help determine the opti- 
mal feature set. Three main areas were focused on: the 
Int.el4S6's bitrst-mode capability, the 4M-l>it DltAM, and 
the emerging 3 6-bit SIMM (single iivline niemoiy module) 
staridcird for PCs. 

Investigations 

The lntcl48tx with its on-hoard SK-b;yte cache, uses burst 
mode to fill a cache line from an external memory sys- 
tc^m. Burst mode, long used in larger computer systems 
but new to persona] computers, is a more etHcient meth- 
od of transferring data. Rather than transferring only a 
single piece of data for each address generated, burst 
mode allow^s multiple pieces of data (typically four 
dwords'") to be transferred for each address. Since subse- 
quent addresses need not be generated, fewer cycles are 
required ro move infomiation. and bandwidth increases. 



•32 bus 



Supporling burst mode, on the other hand, requires more 
complexity than traditional memory or cache controllers. 

Using our available perfonnance tools, the Intcl48€> burst- 
mode capability was matched with various memory archi- 
tectures, ranging from a simple, single-bank memory array 
to a cached, multiple4jank configuration. The single-bank 
memory array was quickly drojjped, because it w^as not a 
competitive stjlutlon. 1'he key finding from this analysis 
was that for 25-MH/. systems, by using the burst-mode 
capability in the Intei466, a DRAM memor>' controller 
communicating directly to the Intel486 could compare 
quite favorably with a moderately sized external memory 
cache* litis was particularly true for cache controllers 
that only suiiported burst mode between the [ntGi486 and 
the cache (or did not support burst mode at £ill). \^lien 
the cost of the cache wtis factored in, the interleaved, 
burst i.ng memory controller w^as the clear preference for 
the Vectra 486. 

Tlie 4M-bil DRAM was scheduled for production about 
the same time the Vectra 486 was to be released. Al- 
though the 4M bU DRAM would provide the higtiest 
memory density available, it was considerably more costly 
than the IM-bit DRAM, which had been in production for 
several years. Being able to support both densities would 
allow us to exploit both the IM-bit and 4M-bit advantages. 
Standard memorj^ configurations could be built with the 
cost-effective IM-bit DRMIs, while large memory arrays 
could use the IM-bit. Furthermore, as the 4M-bit DRAM 
progressed down the production cost curve, we could 
move quickly to it wlien prices became attractive. By 
working closely with some of our key memory vendors, 
we were able to secure prototype and production vol- 
umes of 4M-bit DRAMs fbr the Intel486. 

Previous HP personal computers had used SIMMs, and 
the general feedback from our customers and dealers w^as 
ver>' positive. A SfMM is a small printed circuit board 
with memoiy installed on it (ty^jically surface mounted). 
An edge connector on the SIMM allow^s a customer to 
install it easily into an available connector The typical 
SIMM organization is nine bits wide (eight data bits and a 
parity bit) and the edge connector has 26 pins. During 
Intel486 development a new SIMM organization was be- 
ginning to get attention — 36 bits wide with a 72-pin edge 
connector — w^iich allows a full dword (32 bits plus pai- 
ity) to be on a single SIMM. This SIMM also supports 
presence detect, which encodes the size and speed of the 
module on fouj' of tlie 72 bits, and allows tlie module 
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c-haraderistics to be n?ad directly from the SIMM. The 
new SE^tM was already available in iM-b>te and 2M4)>le 
densities. Both densities use IM-bit and 250K-bit DRAMs, 
hot at the time none used the 4M-bit DR.\M. Working 
with our key i!ieinor>^ vendors, we were able to establish 
standard 4M-byte and SM-byte SIMMs. 

Prom these investigations and other disc^ussions, liie In- 
tel4S6 memory controller feature sei was defined io in- 
clude: 

• Intel436 burst-mode support 

• 2M-byte to 64M-b>1e memory array size 

• Minimum memor>^ upgrade size of 2M-bytes 

• Support for IM-bjle, 2M-byte, 4M-byte, and 8M-byte 
SIMMs 

• Support for shadowing or remapping of I6K-byte memory 
blocks 

• Full support for EISA devices, including bus masters. 

Since many of the features we wanted to include involved 
new technologies, no commercial memory controllers 
were available that supported our feature set Further- 
more, a short investigation concluded that using an exist- 
ing memory controller wdth additional surrounding logic 
to support the new features would not meet our cost or 
performance goals. We decided that the best design ap- 
proach wtts to develop a new controller using an ASIC to 
implement the memor>' control len 

Memory System Architecture 

The memory system is completely coiifained on a S.G-inch 
by-lri.3-inch memory board, and uses a i:troprietary con- 
nector on the Vectra 48fj m(.>llierboard. The memory sy.s- 
tetii sits directly on the 25-Mllz Iniel4B<i bus. 

Allocating board space for the memory controllei', the 
DRAJVl drivers, and other support lo^c, a maxinrnm of 



eight SIMMs can be accomodated on the board. When 
populated with SM-byte SIMMs, this allows a maxinttmi 
memory size of 64M b>tes. This is four times what pre- 
vious HP personal computers had supported. 

In burst-mode opejiations, \he Intel486 is capable of ac- 
cepting one dword each processor clock cycle. At 25 
MHz, liiis means an ideal memory system would be able 
to deliver one dword every 40 ns. Since we were using 
80-ns DRAMs, a simple 32-bil memory^ array was clearly 
not sufficient to meet our performance goals. T^'o possi- 
ble archilectures were investigated: a 128-bit-wide 
menior>' array and a &;l-bit-wide memoo" array. With a 
128-bit memor>' array, all four dwords would be fetched 
on the initial Intel486 memory access, and one dw^ord 
output on each of the four clock cycles. For the €4-bit 
memor>^ array, tw^o dw^ords would be fetched using the 
Imel48t>-genera1e<i address, and two more d words fetched 
using an address generated by the menioiy controller The 
additional adtlress generation requires another clock 
cycle, so the 154-bit memory- array provides four tl words in 
five clocks, ralher than fom clocks. .Although this was 
slower than idea!, the 64-bit-wide memory system allowed 
a minimum system configiuation and upgrade increment 
of 2M b>1es, rather tlian the 4M bytes required in tl\e 
128-bit architecture. We decided the tj4-bit-wide memor>^ 
an-ay provided the best overall solution for the Vectra 
486, 

Fig. 1 show^s tlie block diagram of Ilie Vectra 48G memory 
system. Tlie 3t>-bit SIMMs are organized in pains, creating 
tlie l>4-bil-wide memory army, SIMMs 1, 3, 5, and 7 con- 
tain the kmcr-onier dw^ord, w^lule SIMMs 2, 4, 6, and 8 
contain Ihe higher^order dword. Each SIMM jjair must be 
of the same SIMM density, but different density pairs are 
allowed in the niemoi^^ array The memoo^ airay is fur- 
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ther dhidf^d into upper and lower memory halves (UP- 
PER_MD aiid LOWER_MD) to reduce the ma3dniuin ("apaci- 
tance on each memory data hue. Although this increased 
part count on the board and loading on the system host 
bus, it improved timing margins in the the most critical 
system timing patiis. 

Data transceivers are used to move data betw^een the 
Inlei4S6 and the memory' array, and sit directly on the 
system host data bus (HOSTDATAj31:0}). Since the 64-bjl 
memory system requirc?s two jnen^jiy accesses Tor eao!i 
Intel48ti burst access, latching data transceivers are used 
to output data from the first fetch while the second 64 
bits are read. 

The generation of mcmor^"^ addresses and control signals 
by the memory controller is complicated by the organisa- 
tion of the SIMMs. The IM -byte and 4M'^byte SIMMs are 
organized as a single block of memory (or memoiy bank), 
256K deep by 36 bits wide and IM deep by 36 bits wide 
respectively. Each memory bank has one row address 
strobe and four cokmm address strobe^i (one for each 
b>1e). The 2M-l>yte arRi IM-bytc SIMMs, how^ever, are or- 
ganized as two banks of memory. The 2M-b>te SIMM con- 
tains two IM-byte banks, and the 8M-bytc SIMM contains 
two 4M-byte banks. These tw^o-bank SIMMs have two xow 
address strobes (one per bank) and four shared colmim 
address strobes (to select one of four bytes in both 
banks). A SIMM socket can contain eitJier a one-bank or 
a two-bank SIMM. 

To correctly control the one-bank or twchbank SIMMs, the 
memory controller generates row address strobes and 
row addresses to the array based on the memory bank 
configuration- Each SIMM pair contains either one or two 
banks, depending on the SIMM installed. Eight row ad- 
dress strobes (RAS(7:D)) tire generated directly from the 
memory controller, two for every SIMM pair For a 2M- 
byte or 8 M -byte SIMM the memory corit roller uses both 
row^ address strobes. For a lM-byt.e or 4M-byte SIMM 
only one address strobe is used. The row address appears 
on MA(9:0) when the row address strobe goes active. 

The memory controller also takes advantage of the page 
mode capability of the SIMMs, and keeps tiie row address 
strobe asserted in each memoTy bank. If a subsequent 
memory access falls within an active page (has the same 
row address as a preview us access to the bank), the much 
faster page mode access is performed. 

The column address strobe tmd colunm addresses to the 
array are generated from the four column address strobes 
from the memory controller (SCAS(3:0)), pro\1ding one 
strobe per SIMM pair Because the Intel4S6 can operate 
on a single byte of data, each byte m the array is made 
individually accessible. Each SIMM has fom- columix ad- 
dress strobes, so S2 strobes (CAStSl'O)) are generated for 
the eight SIMMs by combining SCAS(3:0) with eight byte 
enable signals {BEj7:0)), BE(7:0) is also used to generate the 
direction controls (READ_OE and WR1TE_0E) and latch signal 
(tATCH_DATA) to the data Iranceivere. 

Parity is also handled on a b3fte basis. Because of 
memory controller pinont and timing, parity generation 
and detection are implemented using PALs and random 
logic Another PAL is used as a SIMM presence detect 



encoder, which reads four presence detect (PO) bit-s from 
the first SIMM of each pair and encodes them into six 
SfMM_COMFtGURATION bits. This encoding specifies several 
different possible memoiy configiuat.ions, including com- 
binations of IM-hyle and 4M-byte SIMMs, or 2M-byte aad 
8M-byte SIMMs. When used with the EISA configiuation 
utility, the jjresence detect capability allows the user to 
configure memorj' from tlie screen. 

To accommodate the Intel486*s 3^MIlz tmiing (which was 
not available during the design phase of the project), the 
READ_OE signals to the data trance ivers are generated one 
clock early and pipelined through an external registered 
PAL. This scheme ensured that the read |)ath was as fast 
as pf>ssihle. It also gave us some flexibility in host [jus 
timing, in case of changes in CPU tinTlng. 

Memory Controller Architecture 

Fig. 2 shows a block diagram of the Vectra 48G memory 
controller There are seven nu^or tilocks in the memtuy 
controller The configuration registers contain address 
range, renuip and shadow regions, and other memory con- 
figuraiion infonnation typically set by tlie BIOS ai jjower- 
on (see the ailicle on page 83). The 8- bit XI) bus, a data 
bus available on all Pt^s, is used to access all memory 
controller registers because fast access is not a high 
priority at power-on time. 

The memory configuration information, along with the 
SIMM configiuation information from the presence detect 
pms on each pair of SIMMs, is iisctl by the addic^ss block 
to determine if the current memory' cycle on the host 
address bus is in tlie memory controller's address range. 
If it is, the address block will also detennine which 
memory bank is selected, wlielber it is a page hit or miss 
(whether the curre[n row address is the same as an at*- 
tive page), and tlie appropriate DRAM row and column 
addresses ( M A( 9: Q ) ) . 

Memory cycles that appear on the host bus are generated 
either from the CPU or from a backplane device such as 
an EISA bos master IVo indepetidenl state nuichines, the 
CPU state machine and the KlSA/lS.VRefiesb state nia- 
chine, monitor the state of each device. The CF'l' state 
machine is actually two interlocked state machines. One 
nmchine monitors the host bus and wlien it sees a 
memory request, it stiuts a st^cond state machiite. The 
second machine generates iIk* appropriate CPU_CYCtE_CNTL 
signals (page liit or ntiss, dword write, or one, two, or 
four dword read}. The CPU state nuichine is fully syn- 
chronous witli the Intei486 processor clock. 

The EISA/ISA/Refresh state machine generates control 
signals for all other cycles. This machine supports EISA 
burst read or write cycles, EISA- and ISA-compatible 
DRAJVI refresh, and all ISA cycles. Because ISA is an 
asynchronous bus, the EISA/ISA/Refresh state machine is 
a semi-sj^c^u-onous state machine, and uses BCLK (the 
backplane clot^kj, and external delay lines tcj generate the 
BACKPIAf\lE_CYCLE_CNTt signals. 

Tlie Cf U_CYCLE_CNTL and BACKPLANE_CYCLE_CNTl signals aic 
generated on ever>' rtiemoiy^ cycle, Eacli set of signals 
inchides the DFtAM timing relationships I hat optimize the 
respective CPU or backplane device bus cycle. HLDA (hold 
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acknowledge) is ust^l as the select signal to a imiltiplexer 
to tletemiine liie correct set of signals. Once the correct 
CYCLE_CNTL is selected t the corresponding DRAM control 
signals RAS, CAS, and WE are generated for each hank \ia 
the DRAM interface hlock. The byte, word, and dword 
addrcssai.>ility of the niemor>^ array is also h an tiled by the 
DHAJVl interface block, whicii generati^s tlie appropriate 
data transceiver control signals (READ_OE and WRITE_OE). 
For the Vectra 486, all menior>^ reatis are 54 bits while 
inetnor>' writes can be one b,v1t\ oiK^ word Uwo bytes), or 
one dword (lour bytes). 

The row address si robe tirneoul clock is used for DRAM 
timing. The maxinimn tune a page cati l>e open (RAS ac- 
tive) is to \\s. Since it is possible to exceed ttiis limit 
dtiring an EISA l^ursl cycle, continuous page hits, or a 
long lntel48() ictU^ lime, it is necessary to monitor the time 
each b;yik is active. Ii^ight timetjut countei-s, one for each 
bank, monitor the active page time. Coimters are enabled 
when the row address strobe is active, reset when the 
row adflress strobe* grjes inactive, and chxked by an (ex- 
ternal LU>MH7. oscillator. When the lirttecnit hmil is 
reached, RAS_TIMEOUT is generated. The Cmj stale ma- 
ehine and thi" KISA/IS A/Refresh state machine will then 
finish the current memory cycle and allow the DRAM 
interface l>lock to disable the timed-out DIMM page. In 
some instances it Is possible to disable a page without 
incurring any clock penalties because a page hit on one 
bank can be done while turning off a timed-out bank. 

The test, block is used to debug and test the memory con- 
troller chip. An external test pin puts the inemoj-y (^ontrol- 
kT into the test mode. In lesl mode, external a<i dress 
Mnes are used to select which signals and state itiachitU:* 
stales are put on the internal test biLs, The internal test 
bus contaits are available via Iht^ XD biis. 



Fig. 2, Tlio Vectra 48fi memorj- 
ODiit roller 

Burst Mode Read 

All Intel486 memory^ requests are initiated by placing the 
metoory atldress on the host address bus, setting appro- 
priate control lines (le. memoiy read or write) and strob- 
ing ADS#. Fig. 3 shows some of the key timing for a burst- 
mode read cytHe for four dwords. One of the control 
lines, BLAST# (burst last) is asserted if the Intel486 re- 
tiiiests a burst-ntode cycle. If the memory system is inca- 
pable of siipt)orting burst mode, it will return a single 
fiwtirri ;uid aSsen RDY# (ready). If the memory' system can 
sujjport bttrsi mode, it will assert BRD¥# (burst ready) and 
return two or four dwTjrds depending on the type of hi- 
tel48fi rcH^uest. The Intel486-gen crated memory address is 
used to fetch I be first twf* dwords. and a second address 
(incremenled by iw{> tl words) is generated by the memory 
controller to complete tiie four-<lwoni burst read. 

Rt^turning a burst -mode request entails several operations 
within the meinoiy system. For siniphcity, we assim>e a 
DRAM page hit (for a p^e miss, additional cycles are 
required to generate a row addrt^ss strobe and row ad- 
dress)- When the Int.el4S6 requests a burst cycle, it will 
output an adflress for each of the four dwords in the 
bursl. These addresses (and respective data) follow a 
[>articular se(|uence, depending on the initial address sup- 
t>hed by the lnlel486- The memoiy controller uses only 
file itiitial address because the subsequent addresses from 
the hUel486 would nor, meet our system timing. The 
memory controller will latch the initial address and gener- 
ate die identiral st^tiuence *^arlier in the biJT^l cycle. 

There are four possit)le address sequences, determined by 
the stale of HOST_ADDRESS(3:2): 
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Fig. 3. The tinilng relalions^tips 

[jr-twften the signals Invoivf^d in 
doiiTg a burst reat! hJL tjf trjur 
dwnrds- 



Atl dress ciword ciword 1 <iwor<J 2 dword 3 
Sequence atldress address address address 

1: XX 00 XX 01 XX ID xx 11 

2: XX 01 XX 00 XX 11 xx 10 

3' XX 10 XX 11 XX 00 XX 01 

4: XX 1 i XX 10 XX 01 xx 00 

xx = H0ST_ADDRESS(31:4| 

00. 01, 10, 11, = H0ST_A0DRESS(3:Z|orMA2 

The memory coiiti oiler will gei iterate Ihe connect address 
sequence by toggling A2 on each dword, T!ie third iuid 
foiuth dwords differ in A3, so the secotid memory read 
has a column address that differs from the fin^l only in 
one bit. 

To improve burst-mode tinving, radier thaii waiting for 
BLASTS' to be asserted (which may come relatively late in 
the cycle), the n>emory eoiUruller assimies eveo' memory 
read is a biirst-nKjde read, and begins generating CAS, 
READ.0E Jind BRDY# signals. The meniorv^ controller will 
retuiTi BRDVi?' witti the first dw^ord of eveiy read cycle. The 
memory controller will then use BLAST# (now valid) to 
determine if die request was for a burst read. If it w^as 
not, a ROYS' will lie generated, the second dw^ord read ig- 
nored, and the cycle terminated. If it is a bui^^t read, then 
CAS is prechai'ged in preparation for a second nieniory 
read, the first and second dwords are latched in the data 
transcei\'^erBi and the second dword is output. BROV# is 
returned tor the second dword on the next clock cycle, at 
w-hich time the second memory read begins anfl the first 
data latch is opened to receive data for the third dword. 



One clock later, both data latches are open, and the third 
and fourth dwords are put on the host data bus in coti- 
secutive clock cycles. The memory controller completes 
the burst-mode read by generating a SEBDYO# f shaied early 
ready) sij^nal. Tiiis signiil is input to a logic block in the 
Vectra 486 niemoiy subsystem which fonns the RDYi?* sig- 
nal to the lntel48(5 (see Fig, 1). hi the lrUel48G a burst 
mode read cannot be prematurely tenninated, so once a 
hurst sequence has started, all four dwords must b*^ read. 

Conclusion 

The menior>' com roller design beg;:Ui at the same time as 
the HP Vectra 486 SPU (system jjrocessing miit), and re- 
mained the critical path ct>iHponetU lor rTiost of the devel- 
opment schedule. The project team successfully met the 
IIP Vectra 4Sti schedule objective by delivering a fully 
functional first-pass memory controller chip. This chip 
revision was used for the Bl^ Vectra 486/25T production 
until introduction of the UP Vectra 486/33T nienu)!^ con- 
troller version. Fig. 4 shows one i,>f the nieniory bencli- 



Systetn External Cache Size 

Vectra 486 Vendor A Vendor B Vendor C 

Horn I2&K-By!e Cache eiK-Byte Csctie i2eK-Bv!e Cai;he 



Lolua Benchmark 
(Befatlve Perlorinancej 



Integer Sort [K Stonesl 



T.OD 


]m 


.97 


\M 


771, eg 


763.S5 


7fl2.§3 


mM 



Fig. 4. Memorj^ benchmark.^ run on the Vectra 486 aurl oth< r 
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marks nm on the HP Vectta 486 and other cached 
2i>MHz ltiiel48&-basi?d machines, 
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The HP Vectra 486 Basic I/O System 

An lntel48B processor, the EISA bus standard, and a new mennory 
subsystem all required enhancements to the Basic I/O System to ensure 
that the HP Vectra 486 made the best possible use of these new features. 

by \lswanathan S. Narayanan, Thomas Tom, IiMn R. Jones Jn, Philip Garcia, and Christophe Grosthor 



Tlie Basic I/O System (BIOS) is the lowest-level software 
interface between ttie hardware and tiie operating system 
Jn the HP Vectra 4Bt) j>ersonal computer, Ttu^ BIOS con- 
sists of a power-on self-tesl and function support for the 
DOS operating sysleni. The power-on selTtest iH-rtbrins 
testing and initial! mtioti of tlie vtirious components of the 
system and loads die openiting system. The rest of the 
BIOS supp(ri1s fuitcfioMs to access the various DOS de- 
vices- This aiticle dest rihes the (ievetopmenT jirocess ami 
the features inconJ*>nvied into tire IIP Vectra 48t) BIOS to 
support the lntel480 mic coprocessor and the Extended 
Inckistry Standard Architecture (EISA). 

BIOS Souree Base 

The Vectia 48fi BIOS code was heavily leveraged front the 
scHirtT ccKie of tlu* Vectra BS, RS. and QS pej-sonal (*om- 
l>uter series, which supixul the HP-lilL (liun uur irnerface 
hnk) BIOS extensions (EXBIOS). Tlu^ EXBIOS supptjrt 
was stripped off and suppoH for EISA, the microDIN 



mouse, and other eiihancements were added to create the 
Vectra 486 BIOS (see Fig. 1). 

Tcj m^LxiiniKe BIOS It^vera^e for' future systems, team 
members focused on keeping a laige part of the new 
source files retisable. A common coltection of reusable 
software riu>d[iles ensures a more rom].vatibl<^ and etisily 
upgradalile snttware sy stent. This comnKinalily ensures 
I hat during de%'elopment, pf>tentia] com[>atiljiIity pjoljlems 
only have to t>e addressed <jnce, and whcEi a (compatibility 
f)robkMu in a released protiuct is fixed in a common roiK 
line, tht^ fix is dotu^ <mce mid automatically gm^s into all 
sul>sc^quent software releases. 

The BIOS development of code was shared between the 
engineers at HP's C:alifomia Personal Computer Di\ision 
in Sunn>^^ale. California and HP's (Grenoble Personal Com- 
puier Divisioii In France, llw conflguralion for transfer- 
ring files back and forth between tlie two grf)U|)s is 
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Fig. 2. nuHinuinicaLitHi lierwork 
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in Oenobl*% France. 



shown in Fig. 2, This rode sharing createcl issues relate d 
to ensuring tile security and tracking t^hanges to tJie code. 
For this reason the BIOS source base is managed by a 
software rcvLsitJii control system. The soiu'c^^ files are 
stnicTured intij connnon and niachine-sjjeciric tlirectories. 
The machine-specific files contain code tliaf handles tlic 
initialization requirements of different chip stHs and differ- 
ent processors and processor speeds. EISA jind ISA dif- 
ferences are also handled by the code in these tiles. 

EISA Iintiallzation 

One of the rnusi ini[)oniinf IVauireH of ilip KISA architec- 
ture is its al^ility lo detect I he I/O expansion boards in- 
serted in the system's motherboard slots. The configura- 
tion utilil.y easy config generates infonnation for eacii EIvSA 
or ISA card installed in a sysiem expansion card sloi. 
When ihe user is satisficfl with tlie sysiern t*onfignration 
with either the defa tilts prcsenled by easy config or afier 
making any desired changes, the configmation is stored 
in non\iolai:.e RAM. 

The configuration files for eacli board contain function 
data strui tures for each slot that provide information on 
the DMA inili^lizalion, IRQ {interrupt requesl ) trigger, 
menior>' infomiation, and I/O iniriahzaiion. easy canffg re- 
solves I/O initialization, mf^mor>' conflicts, and identillca- 
tlon for tlie inrlividtial expansion boards in each slot. 

EISA Coiifigaratitin Support 

Support for storage and retrieval of EISA configuration 
information is provided by 8K b>1es of nonvolatile RAJVI 
and l>y system BIOS support routines. The EISA configu- 
ration utility easy config uses these routines to cleai" non- 
volatile RAM, store EISA configuration information (on a 
slot-by-slot basis), and retrieve infonnation for all func- 
tions of a slot (brief format) or for one fujiction (detailed 
format). Fig, 3 stiows some of Ihc processes involved in 
retrieving data from or storing data to the nonvolatile 
RAM containing conliguration data. 

The system BIOS power-on software also retrieves the 
configuration data to initiaiize the hardware in each slot 
Mter the system boots, other system drivet^, utilities, or 
the opefiitin^ system may also store antlor retrieve con- 
figuration data (or any other data) fiom nonvolatile RAM. 



To accommodate vaiious operating envirormients the 
BIOS routines that interface to the nonvolatile RAM can 
operate in the InteI486's real or protected modes. In real 
mode, Ki-hil segments and offsets are used to address a 
IM-hyte address space. In protected mode, segiticnt regis- 
ters become selectors into descriptor tables which witli 
ofTsets allow for 16-bit to 32-bit addr tossing (up to 4 giga- 
bytes). 

To save space, input data is compressed by the caller 
be fort* it is stored in nonvolatile RAM by the BIOS rou- 
tines. When cori figuration data is retiieved from memory 
it is expanded liy the BIOS I'ouiines before t>eing passed 
to the caller. Exprntding the output data involves padding 
variable-lengt h data fields mid blocks iino fixed lengtlis. 
Slot contigu rati Oil data consists of a variable mm\ber of 
variable-length fimction blocks that describe eacii function 
of a card in an EISA or ISA slot. The function blocks 
consist of fixed and variable-length fields and vaiiable 
repetitions of fixed and vajiable-length suhfields. These 
fields eonsisi of descriptive texl infonnation and menujry. 
Interrupt, DMA, and I/O resource and configuration data. 
Free-form tlata can also be stored in some of (Ik^sc fields. 
The slot connguration data is stored seqtjent tally by slot 
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number (including empty slots) until the last ph>^cal or 
virtual slot is reached. The nijimnuiii size of a slot's eon- 
figuration data is zero (empty) and the maximum size can 
l>e as long as the remaining av-ailable space in nonvolatile 
RAM. 

To access nonvolatile RAM data effideniiy (in terms of 
speed and space), a lable at>proach is used. A table of 
pointers that point lo slot conflguralion data blocks is 
allocated dynamically and grows inwarti from one end of 
the nonvolatile RAM. Tlie data space for slot ronfigum- 
tion bioc^ks Ls also allocated dynamically and also grows 
inward but from the opposite end of nonvolatile RAM 
{see Fig. 4).UTien the pointer table and data space meelp 
the nonvolatUc RAM Is fulL Tliis technique saves menior>^ 
space and allows for a single look-up to reach any data 
bloi'k. 

Fower-on Initialisation 

Ulien tilt' system is rebooted the BIOS initializes one 
EISA or ISA slot at a time and one fimctinn at a time 
using the coiiligurdtJf.)n infonnation stored in nonvolatile 
RAJVi The mitializalion proceeds in two steps; error 
checking is performed first and then the slot is initialized. 

Error Checking. The systcrti ROM BIOS be^ns the initiiil- 
ization <inly if Uie nonvolatile memory^ s checksum is 
good. The BIOS also has to check whether the correct 
card is installed in tiie right slot before it itutializos the 
card in tliat slot. Tlie BIOS checks for the following com- 
binations in each slot, 

• A slot could be defined as empty according to the config- 
viration datii, buf the user may have plugged a card int o 
the slot. 

• A slot could be defmed io have a particular identifier ac- 
cording to the configuration data but may be read as 
empty. 

•A slot could be defmed to have no readable identifier ac- 
cordinj^ to tlic t onfigiiration data but BIOS reads an idei\- 
lifier fruiu ilie .sl(>L 

♦An identifier read fion> the slot may not agn^ with the 
idcntifiei* in the ctaifigiu-ation data 



Nonvolatile R^M( 




L Configuration 
^ Oats 



Poinle^s 



Fig, 4. OigamKation tjf poinurK mni sUn ( uririMuraiifui rttiM In 
hunvolalilf ttA.M- 



An identifier for a slot is checked by reading certain slot- 
specific I/O ports as defmed by the EISA specifications. 
After verifying that the slot that needs to be initialized 
has the correct card in it, the BIOS start the initialization 
for that slot. Fig. 5 shows the error chec'king process 
performed by the BIOS during initial izatlon. 

Slot Initial ization. As in error checking, slot initialization 

data comes from the configuration data in nonvolalile 
raemoi>\ The configuration data for a slot is retrieved as 
a bloc^k of data* and there could be many blocks of data 
for a particular slot. Fig, 6 siiovvs the fiow for slot initial- 
isation. 

Slot initialization starts with the BIOS code reading a 
block of data from nonviolatite memor\^ for a particular 
slot. It checks to see if there are any DMA initialisations 
for that slot. If DMA Is not shared, then the BIOS initial- 
izes the extended DMA. registers defined for UvM slot. 
Next the code checks to see if the slot has any IRQs tliat 
need to be set as edge- or level-lriggered. It tlieti sets up 
the cache map for noncacheable regions as defined for 
that slot. Tlie code then continues with the I/O niitializa- 
tions if any. Once tliis se<iuence is complete the code 
continues with the next funrtion for the slot until all the 
functions are completed for that slot. 

The BIOS provides a feature that allows the usei^ to make 
blocks of nientory cacheable or not This is very useful 
for boards that have memor^'-mapped I/O. Tlie BIOS 
builds a cache map in ^^'hiell each bit defines the cache 
on/off state of a particular segmem (each segment is 64K 
bytes). A function in the configuration infom^ation for a 
slot can define the start adciiess of the memory and the 
lentil of niemoiy' ^'^>f which racliing needs to be turned 
on or off The BIOS irtitially sets all segments' teaching to 
be on. It then checks for segments of mt^moiy^ for which 
the cac^hing needs to lie tiinied off and then turns caching 
otr tor the segments that are within the memory length 
specified. The caclie map Ls updated and is later tisetl in 
the boot process to initialize a OIK in! statii- R.'\M, which 
the hardware uses in Its cache on/off logic. Each bit of 
the static FIAJV! rt^jresents a segment, allowing CAK .seg- 
mi^nts (or tour gigabytes) to be represeuted (sei^ Pig, 7), 

The BIOS then initializes the various I/O ports as defined 
in the configuration data. The I/O c;in br: 8-bit, IMiM, or 
32-bit reads or writes. The configuration data alsc* ticfines 
the mask for the particular I/O porf. Thus, lite I/O port is 
read, tlu^ data is masked (ANDed) with the n\ask vahie, 
ORtxl with tlie bits that need to be set, and written back 
tD the 1/0 port. 

Finally the BIOS enables the boiu-d in the initialized slot. 
Any time the initialization tailSj the BIOS makes sure that 
the system can boot from a flexible disk and thai die 
video is initialized correctly This is done so that the ma- 
cliine is in a inininmm working slate so that the user can 
execute easy config and reconfigure the system. 

Variable Speed Control 

I^'or backwartls coni|>atibility, it is sometinic^s necessaiy to 
reduce the speed of tiie P*'. This is pain ituilarly true for 
copy-protected software applications that are speed sensi- 
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Firi- 5, Error checking during power-on initiaJizatioiL 



tive. The Vectra 486 cmi ivducc its speed for all opera- 
tdonSj or only for flexible disk operations. The system 
BIOS is responsible ior tfiis control. To change speeds tiie 
BIOS progranis t.lie ditty cycle of a square wave generated 
by a hardware thner wbich modulates the Spd^Hoid^Req 
(liold request) input of the microprocessor [see Fig. 8a). 

If the microprocessor did not have an intemal cache then 
it would effectively be idle wliile it relinqLiislics tlie bus 
dming a hold request. Its effective speed would thereby 
be reduced by the tnodulatiot) factor. Sbice tlie hitcl480 
has an intemal cache it will continue execution, even 



wheii lu a Hold slate, imtil a cache miss occurs, wlieu it 
uiusl wait for tlie bus. Therefore, to control the micropro- 
cessor's effective speed accurately when it is leduced 
from its inaxinimn (unmodulated) value, it is necessary to 
disable and flush the processor's intemal cache. With its 
iruemal cache empty, the processor will hah execution 
(because of cache misses) mitil the modulated 
Spd_Ho1d_Req signal is dcasseiled. The BIOS progrmns an 
I/O pon which disables and flushes the intemal cache \ia 
the Iiitel486 control lines. Tliis avoids haiing to use the 
Intel486 control registers to disable tJie cache. These con- 
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Fig, 6. Flow for slot initialization. 

trol rcgj^Let^i could he in use by fiUuT soHwarr apjilica- 
tioiis and might be dLsntpted by the action*^ of the BIOS. 

If the speed is restored, or after a flexible disk access 
when at aiitospeed* the BIOS reprogranis the cache con- 
ttol I/O port and the duty cycle of the square wave (see 
Fig, 8b). Therefore, the controi state of Hie cache is main- 
tidned after resumpticjn oi niaxiintim siieed \^ithoul inter- 
It'iing with resources (Intel48(3 control registers] tiiat ap- 
IjJicaHons itiay depend upon, 

Miero-DIN and Security Features 

The input system consists of three eoniponents: the ijiput 
devices. BIOS functions, and the lT\tel 8042 keyboard {con- 
troller. *rhe 8042 keyboard ctinl roller conuiiuiueates with 

"At auujapaed the s:yiitem operates at its highest speed unmodulaied and switches to an 
affeaivg speed otS HHfe (modulated Qoly when it is accessing a ftexitile disk 



the kej^board and an auxiliar>' device in a bidirectional, 
serial fornaat with a synchronized clock generated by the 
input deTrice. The auxiiiairy de\1ce may be any t>pe of 
serial input device compatibie with the 8042 keyboard 
controller interface. Some of these are: mousey touchpad, 
trackball, and keyboard. 

The SM2 keyboaixl controller receives the serial data, 
checks tlie parity, translates keyboard scan codes (if re- 
quested), and presents the data to the system as a byte 
of data. It also provides a password security^ niechaiiism 
to support the network ser\-er mode and application soft- 
ware. 

Additional securitv^ features of the Vectra 486 PC are the 
power-on password and tlie mechanical keylock. Both 
schemes are designed to prevent unauthorized access to 
the PC. The BIOS provides the softwaie lo support the 
power-on password feature whenever the Vectra 486 is 
powered on. 

The password function c^an he configured via the easy 
confjg utility to request a passw^ord either when the PC is 
powered on, or only when a user needs to use the input 
devices. II the PC is configured to request: a password, 
the BIOS wiU display a graphical key symbol to prompt 
the user for the password. If the user ty]^es in the correct 
password, the PC wjlJ continue with its initialization, 
Othervtise, the BIOS allows tlu-ee attempts for the user to 
type in Uie password before haltit^g I lie CPl'. If the user 
knows the correct password, the BKJS will allow the user 
to change or delete the password during the power-on 
sequence. 

When tlie passwortl is set up to allow limjteil access, 
which is also known as the network server mode, all mi- 
cro-DIN input devi<^es are disabled via the 8()42. A PC 
configured as an unattended file server would typically 
install the password in the network server motie. In the 
network sender mode, if the BIOS tielects a diskette in 
drive A, it will iironipt the user for the installed password 
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because an unauthorized user may be trying to gain ac- 
cess to the PC via a bootable diskette. 

The mechanical keylock, used for locking the input, de- 
vices, can be used in coryimction with the power-on pass- 
word to provide maximum security. If the keylock is in 
the locked position and the ptissword function is installed 
to request ttie password at power-on, then the user will 
have to unlock the keylock be to re typing the password. 
But if the password function is installed in the network 
ser%^er mode, the keylock doesn't have to be unlocked to 
type in the password until a user needs to use the input, 
devices. 

Since the user may occasionally forget the installed pass- 
word, the BIOS supports a DIP switch within the Vectra 
48(3 that disables the password, I'he BICS uses this 
switch to allow tlie user to erase the password without 
any knowledge of the installed password, 'this switch is 
also used to forbid the installation of a password by an 
unauthorized user To access the switch, the user must 
unlock a mechanical keylock lo open the PC. 

Shadowing and Remapping 

The system niernor>' of a Vectra 4S€} Is parhtioned into 
three areas: base memoiy, reserv^ed memorj', and ex- 
tended memory. The base memory is within the physical 
address range from to 640K bytes. The reserved address 
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Space is within the physical address range from f>40 bytes 
to IM bytes. Lastly, the extended n^emory area is all 
memory above IM bytes. This memory architecture is 
known as the PC AT system memory architectme. 

Most software applications typically use the base area 
and some use the extended memory area Tlie reserved 
memory is set aside for special sysierti functions and is 
generally not available for typical software applit^ation 
iLse. The reserved memt>ry is organized to support: the 
main functional contf>onents of a microcomputer (see Fig. 
9). The video display area and the \ddeo RA^I can occupy 
the lowest portion of the reserv^ed address space, ACJOOO 
to BFFFF Tlie \ideo ROM BIOS can begin at COOOO and 
typically ends at C7FFF. The addrt*ss space that begins at 
C:8000 and ends at DFFFF is resented for special 1/0 
adapters anti rnemorj' drivers. FAHM) tt) KFFFF is used 
for onboard t>ption ROMs or baekijlane I/O lU)Ms (Itj- 
cated in the I/O slots for ISA or KLSA cards]. FU(K)0 to 
FFFFF is reserved for the Basic Input/Ouput System (sys- 
tem ROM BIOS). 

Since the introtluction of this architecturej the cost of 
nienrr»ry devices has declined while the density and speed 
of the coinponents have increased. Processor speeds have 
incrciised far beyond the speed that any programmable 
read-only memory device can effectively support. With the 
advent of 32-bit i>us architectures, systems am physically 
address four gigahvies of niemory, which can be used to 
support larger, more complex software applications. 

Better system perfoniTance can be obtained with efftcient 
management of the reseiTed memory. The Vectra 486 
makes use of two memory management schemes: ROM 
BIOS shadowing and memory remapping. ROM BIOS 
shadowing is a method used to speed up ROM memory 
access so thai portions of reserves! memory that are fre- 
quently used can be accessed as quickly as possible. 
Memoiy^ renmppuig permits unused reserved memory to 
be used as extended niemory. 

Shadowing. BIOS anti \ideo ROM BIOS routines and data 
are stoipd in EPROM (electrically programmal>le read- 
only memoiy'K This tvpe of rtiemor^' is considerably sk>w- 
er than d>Tumiic random access memory (DR.AM). Sirice 



88 Ociober 1 9D 1 Hewtett-Packairi Joiim;] 1 



)Copr. 1949-1998 Hewlett-Packard Co. 



the BIOS and vid^o ROM routines are frequenUy used by 
the ^^em, contents of the ROM BIOS and video ROM 
are copied tnlo memory ha\1ng a faster access time. This 
techniqiie is knowii as shadowing. 

The conventional organization of the reserved address 
space, m Fig. 9, shows the locations of the system RAM 
and BIOS ROMs. In the Vectra 486, as in other microcom- 
puting systems, the cotiventionaJ organization of reserved 
nremoo' is enhanced to accommodate some additional 
system RAM which is located at the same address loca- 
tions as the sj'siem BIOS and video ROMs (see Fig. lOj. 
This memory is called shadow RAM Mother advantage 
of shadoT^ing is that menaor>^ fetches for the Intei486 can 
be accomplished four times faster because ilie EPROM is 
an 8-bit device and system DEIAM consists of 32-bit de- 
vices. 

The conventionaJ approach to shadowing is to copy the 
contents of the system ROM BIOS and video ROM BIOS 
to some temporary location. The ROM is then disabled 
and the shadow RAM is enabled. THE BIOS information, 
which currently resides in the temporary storage area, is 
copied into the shadow memoi^ at ihe same memory 
address locations from which the information was origi- 
nally retrieved. FoUovting the shadowing process, any 
data that was originally in ROM will be a<*cessed from 
the corresponding location in the faster shadow RAM. 
This approach requires that the state variables of the 
memoiy controller indicate w^hether the ROM or the shad- 
ow RAM is being accessed and if write access to the 
shadow memor>^ is permitted. These state variables pre- 
vent dat^ corruption by ensuring that eitlier the ROM or 
the shadow RAM is enabled at any time, but not both, 
and that, once copied ^ tiie contents of Oie shadow 
memory cannot be inadvertently overwritten. 

The disadvantage of the conventional shadowing method 
is that system memory c^ontrol states are wasted. The 
Vectra 4.% overcomes this [irtibleni by eliminating Ihe 
ROM and shadow^ RAM enable^ variable. The write protect 
and shadow RAM enable variables are combined into a 
single state variable. On power-up, Ihe default state of the 
system will read FilOS (systetti aiKl video R(_)Mj data from 
ROM Mxd write this data to the BIOS address space in 
the shadow RAJVI. Whenever the shadow RAM is enabled, 
data read from the BIOS a*klress space will be read from 
the shadow^ memory' imd all write operatitjtis 1o addresses 
within the BIOS address space are ignored. The shadow- 
ing metliod used in the Vecira 486 system restilts In a 
tremendous savings of hardware imd valuable system 
ROM BIOS code space. The additional step of copying 
BIOS data is eliminated since data can be copied directly 
from ROM into the shadow RAM. 

Remapping. It is often the case that following completion 
of llu' shadowing process, portions of the RAM in the 
reserved memoiy area are not used. Since topical soft- 
ware applications are not designed to be able to access 
reserved ttieniory for general storage puqjoses, ihe free 
portions of reserved RAM remain unusefl A .s{)ftware ap- 
plication can direcHy access reserved menioiy, but with- 
out prior knowledge of the configuration of ihe sysfcm. 
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Pig. la* Shadow RAM, 

the application could unknowingly cause a device to mal- 
function by corrupting sensitive data. One approach to 
this problem is to incorporate an expanded memory man- 
ager into the system configuration. An expanded memory 
manager manages the free reser%^ed memory by allowing 
the application to use the space as additional base 
memory, and makes the sy stent appear iis if the amount 
of base memoiy has l>een expanded. The disadvantage of 
using an expanded memory- driver is that it is used during 
nm time. This mode of 0|)era1 ion degrades system perfor- 
mance. The expaiided memory manager also requires 
memory space for storage of tJie software routines, there- 
by leaving less memory for the application to i^e. 

Another conventional method is to remap portions of re- 
serv^ed memory to the top of die physical address space 
of the system. The disadvanlage of this methoci is Liiat 
the memory location to which the free memory is moved 
sometimes does not border on existing memory locations 
and results in creaiing a noncontiguous memoiy structure. 
Most applications <:annot make ust* of fragmeruetl 
memory. Also, Ihe conventional remai>]>ing stiieme is a 
machinespecifit feature, and therefore, all sfiflware ap- 
plications must be custoniiy.ed to take advantage of the 
remapped meniory. 

The Vectra 486 solution to riiemory reThappii^g uses the 
s>'stem <'onfiguration informal ion in notnolatile RAM to 
instruct the memory eon I roller how io organise the sys- 
tem memory. As km PlISA tnachine. Ihe Vectra 486 has an 
autocon figuration piogram wliich iderUifies system compo- 
nents anfi allocates system resources to obtain maximal 
sy ste ni j lerfo rinan ce. 

Memory remapping in the Vectra 486 is a two-step pro- 
cess. The first step us to find tlie largest contiguous 
chunk of free reserved memory that ctm be remapped. 
The video RAM space (AOOOO to BFFFF) is generally not 
used l)ecause the video cards and the embedded subsys- 
tems are rurreutiy made wiih their own RAM. On-board 
option ROMs, whicli physically reside at EO(M)0 to BFFFF, 
are rarely used, and ihe \1deo BIOS address sjiace, Ct)f.K)0 
lo t'8{)tK), fragnuuMs the rt^sen^ed meni(jry^ area. The way 
lo create the largest contiguous seclion for resei'v^ed 
mcEuory is to shadow the video BlUS in shadow ntemory 
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at EOOOO, provided that the system docs not contain on- 
board option KOMs aiul if I/O consirierations of the \ideo 
BIOS support poitability. This |iaradigiii creates a 256K' 
byte fAOOOO to DFFFFJ c^hurvk of nieniory thai can hv 
remapped (see Fig. 11). The 32 Kbyte portion between 
EBCIOO and EFFPF is uinised. The system memory control- 
ler is told what area of reserved mcmor>' is to be re- 
mapped. It must also be noted that systems that use the 
DOS shell rely heavily on tlie system BIOS arul video 
BIOS routines, so maximally, only 256K bytes of memory 
is available for remapping Systems thai use Ofl/2 and the 
UNiX^= opeiaiing system can maximally remap all of re- 
served memoiy because these ot>erating systems replace 
system BIOS and video BIOS atul supply all of their ovi^n 
drivers. 

The second step in the remapping process is to determine 
where the physical existerue of memory ends. The sys- 
tem BK>S knows this inlonnaiion following the system 
memoiy test proeetiuie dining ihe system power-oi\ self- 
test. This address is passed to the system memory con- 
troller Following the first step, the memory controller has 
Lhe necessary^ information for nunnoty remapping. The 
system menjoty controller then does the proper address 
trjmslation, 

BIOS shadowijig and resetve4:i memory remaii[>ing are 
powerful system features that enhance system perfor- 
mance and make better use of system resources. BIOS 
shadowing is a conunon feature among all machines cur- 
rently on the market. Its primiuy adv^antage is to bring 
more pailty between processor s])eed and liOM access 
times. To implement this functionality in an eflicient man- 

*IINIX (S a regisiBfed Trademark of UNIX Svstam Laboratories Inc, in ttie U.S.A. and other 
CDuntriBS 
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ner save.s hardwai'e and rode space which translates into 
a cost savings to the customer. 

System Memory Initializalioii 

Finite stale machines implemented in software ear* be a 
very powerful tool. For a system^s BIOS, a soflwai^e finite 
state machine is ideal for component test situations in 
which scratchpad memor>^ is not available. This technique 
is used in lestmg the system mcmoiy configuration in the 
Vectra 480. 

The meitioiy subsystem ol tlic Vectra 486 is a two-way 
interleaved, linear memory architecture. The syslem 
memoiy l>oard lia.s four memor>' banks. Each bank can 
hold two juemoiy modules. The Iwo memoiy^ modules are 
tW'O-way word interleaved. The banks of memory' are or- 
ganized ill a linear fashion. See Uu' article on page 78 for 
more infonnation about 1 he Vectra 486 memory^ subsys- 
tem. 

Tlie memory modules are packaged in smgle in-line 
memoiy modules iuui come in IM-byte, 2M-byt.e, 4M-byte, 
and SM-b^fte vaiieties. The IM-bvli^ and 4M-bytc modules 
are single-density modules. The 2M-t>yte and 8M-byte 
modules are double-density modules. Kach memory bank 
on the system memf>ty board must c(mtain a pair of 
memory modules tliat aie th(> s^mie size and have the 
same density type. Moreover, density restrictions require 
that all memor>' banks contain memory modules of die 
same density type. The linear stnicHire of the memory 
subsystem requires that the amoinit of inemoiy in a barik 
be less tlian or equal lo the amount of memoiy in a bank 
that logically precedes it. Tlie exception to this rule is the 
first bank because no other memcDty bank precedes it. 

Before system memory can be tested, the memory sub.sys- 
tem configuration must be veritled. The power-on self-test 
procedure in tlie system BIOS is responsitiie for this task. 
The use of system resomx'es must, be kept to a minimum 
because system memory is not avaiiai>le at this stage in 
the system pow^er-on iuitialization process. A software 
finite state machine is ideal in this situation, since cjnly 
the registers within tlie processor are available. Th(» finite 
state control is guided by liie memory module identifica- 
tion encoding (each memory module lias information en- 
coded within it that specifies the size iiiid density type of 
the module). The memoiy state matrhine evaluates the 
identification for each memoiy l^ank aEiil veilfies tliat the 
current memory configuration (linearity, miifonn bank 
densities, etc.) is valid. 

The software finite slate method is very effective when 
considering thai each of the four banks can have one of 
five tj^pes of memoiy modules. The mmiber of possible 
memory eonfigurations is 4^ or 1024 possible configi[ra- 
tions. Of the 1024 possible configur<itions, 28 are valid. If 
module density enoi-s ar*^ found first., then die linearity 
check can be done willi a soft \'i are finite state maeiiine 
wifii four states. Fig. t2 shows tlie finite slate machine 
for testing the Vectra 486 memoiy configuration. 



Fig. 11. Remappii\g. 
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Defect Ttacklng 

Because BIOS snurce code was shared among indepen- 
dendy inaruij^rtJ jjrojt'cts in dirtVrent lotalions, BIOS prob- 
lems had to be Uaekecl not only for the Vectra 48(> prod- 
uct but also for .several other HP i)crsfynal roniputer 
products as will 

To kf»ep track of prerelease problems across the various 
pn>jeets ami to prn%1(le a means of coliecliiig more global 
[irotess improvement melries, a custom tlBASE IV ' ap- 
plication was vmtten for use by all of the BIOS teams, 
Prolilems rt^ported on the Vecira 486 were sent by testers 
to a special elerlronie mail accounl to t>e entered into 
the database. The use of a slaiidarti problem tonn al- 
lowed the collection of valuable statistical iis welt as 
problem-sperine infonnat ioti. Irifr^rmation about BIOS 
problems in ct>rmiVfm llles w^ls stiartnl directly with each 
fcain by excbajiging dalabast^ Qk^s. The llexiliility of I he 
PC databasi^ application allriwed each team to adapt tJie 
database application to their needs without affecting the 
ability to share data. This was important, because several 
BIOS teams could ha\e Ijccn invoki^d in resolving atiy 
one problem. 

As (vach problem was in\ instigated aiifi resolvefb stiitus 
infomiatiun was entered into I he database. Detailed in- 
foniiatjon, such as which code module contained the 
I^robiem and when the problem was inf rod need, was 
readily available. The typical wtu'kly stalu.s report con- 

'DBASE tV <s ^ regnTOre^ US, trademark of AshtonTafe Corp 



tained a sinipie smiiman- of the acti%*e problems, the 
problem owTiers, and their current status. One BIOS team 
member acted as the bug manager and helped keep ev- 
en one informed of the pragress being made to resoh e a 
problem. 

BIOS QualiflcatioD and Test 

The BIOS qualiricatioii efifon for the Vectra 4W project 
was m\ iniprovenient over previous BIOS deveiopment 
efforts. Because of m^or revisions to the BIOS in the 
Wctra 486 and the need to produce quality soft^ are in 
minimum time* a special BIOS qualification team was 
fomit^J, This team consisted of four engineers and a soft- 
ware technician whose main job was to verify that the 
BIOS specificaiions were correct In the past, the job of 
qualification of the BIOS was left up to the de\^eloper of 
the BIOS code. For the Vecira 186, it was fell that riuahfi- 
cation W'Ouki be more thorough if the persons developing 
and executing the tests were not the individuals (levelop- 
ijig the BIOS code. 

To make best use of our Umited resources, two types of 
test strategies were developed: white box and black box 
testing. Black box testing used a high-level lajigiiage pro- 
gram, such as C, to verify the ftmcliDttality ^:md (quality of 
the BIOS. The C functions invoked DOB functions, BIOS 
fund ions, and I/O registers to test the BIOS. This was the 
stajidard method of testing most programs. Ilow^ever, 
when testing the BIOS, we did not at W' ays have the 
luxury of relying on an operal ing system such as DOS 
because much of the BIOS functionality had to be tested 
fhiring the machine initial izaticjn, and w^as inaccessible to 
higii-Ievel progr^uus. 

An alternate^ nietbod was developed using some new ap- 
proach(\s and working with sjiecial development tools to 
perfonu white box testing. New features such as BISA 
initialization, memory Initializatkm, aiul shadowing rou- 
tines were tested using this dpimnwh, Thi?* metlKHl forced 
two engmeers to read and iindetsland the actual <iHJe: 
the original dt^signer arid the one developinj^ tlie lesb This 
task alone required aji in-depth understanding of the BIOS 
modules on an instruction-by-instniction biisis. The con- 
cept of having two people intimately understand eacli 
tmHiult' is not new. but lypically resource limitalions 
niake sucf^ an arrangenu^rtt a luxuo'. 

There were many advantages to this tyjje of testing. Kor 
one thing, it allowed us to simulate some of the system 
errors. For example, if the user had an invalid memor>^ 
coftllgunttinn. this error cmild be sinuilated without e%'en 
changing the inenioi'y insi(ie th(^ cuinputer. FurliiennfjrCj 
ail tJie valid memory configuration could be tested via 
this liiogram. There were well over IbOO niemrM'y configu- 
rations 1 1 lilt cuiitfi be lesled through one anlnnuilcd [>rt> 
gram. Nornuilly, Iliis process would involve a tecbnU ian 
physically chiuigiiig the configuration eacii lime, AnotJter 
advaiUage was that the BIOS c*ould be* tested without the 
hardware. This prove<i lo be veiy helpnil since the BIOS 
was l)eing tlevelojteci liefiae the hajxiwajc was available. 
Willi this rnetliod, two tasks could be ilone concurrently. 
On<T the hardware was available, the tests c^otihl also be 
executed on the haidwiu^e. 
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The test strategy that was developed by the BIOS qiialiJj- 
ration team enabled tlie teani to perform tests on tlic 
BIOS that would noniially not have been done. Once the 
tests were developed, they eon id be added to the test 
suite for regression testing and other BIOS related tests. 

Conclusion 

The HP Vectra 486 BIOS development effort was a major 
milestone in HP's Personal Computer Groups soltwai'e 
development history from tJie perspective of both new PC 
technology advances supportcHi lukI new pr<JC'Csses 
introduced. Support for new teclinoiogies and I'eatures 
iii<e the EISA architecture and an advanced meiTioiy con- 
troller was incorporated into BIOS with high quality while 
meeting system schedoles. 

New or enhanced processes with their associated tools 
were incorporated to meet customer needs and IIP busi- 
ness requirerTienis. A customized source version control 
process and tools allowed efficient, multi-she, simuha- 



neous PC BIOS development with maximum code reuse. 
Brand new defect tracking and component quaJifi cation 
processes and tools allowed quality BIOS development 
coneurrenl with PC hardware development. 
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Performance Analysis of Personal 
Computer Workstations 

The ability to analyze the performance of personal computers via 
noninvasive monitoring and simulation allows designers to make critical 
design trade-offs before committing to hardware. 

by David W, Bleviiis, Christopher A, Bartholomew, and John D, Graf 



Today's high-perfomiance personal computers are being 
used as fdc scr\-en>, eui^ijieering workstations, and l)iisi" 
ness transacLion processors, aieas previously dominated 
by large, eosUy niainfranies or minicomputers. In this 
marker, perfonnance is of parainoimt importance in dlf- 
ferendating one product from anolfier Our objfclive at 
HP's Personal C'ompuler (itouij's peiformance analysis 
laboratory is to ensure that perfomiajice is designed into 
TiFs ofTering of personal computers. Tb achieve this, anal- 
ysis of a personal computer's subsystem workloads and 
predictive system mt dieting can be used to ick^ntify bottle- 
necks and make architectural design decisions. This ar- 
ticle describes the tools and methodologies u.sed by HP 
engineers to accomplish peribmiance analysis for person- 
al contputers. 

The toolset currently being used at the performance anal- 
ysis laborator>^ consists of specialized hardwaie m\d soft- 
ware. Typically, the hardware gathers data from a system 
under lest arid then the data is post processed by the soft- 
ware Lo create reports (see Fig. 1). Tliis data Ciin also be 



used to drive software models of personal computer sub- 
systems. 

Hardware-Based Tools 

The tT^'o hardware-based performance analysis tools 
shown In Fig. I are the processor activity monitor 
(PMON) imd the backplane 1/0 activity monitor (BIO- 
MON). Both tools are noninvasive ir^ that they collect 
data without interfering with the nonnal acllviiy of tiie 
system under test. 

Processor Activity^ Monitor 

The processor activity monitor is a hardware device that 
monitors a personal contputers microprocessor lo track 
low-level CPU activity. The PMON is sandwiched hetw-een 
the contputers CPU and the CPI.' socket (see Hg. 2). The 
PMON monitors the processors address and control pins. 
For each CT'U oi>eration, the PMON will track the dura- 
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tion and address of the operation and output the riesults 
to the data capture device. 

Gathering statistics on the activities of a personal com- 
puter's microprocessor can be very useful in making de- 
sign decisions about the arrangement of the sui>port cir- 
cuitrj' (e.g., cache and main memory, I/O bus interface, 
and bus I tries). Iti addition, trace IUcs that detail the 
CPU's requests 1o Ihc^ memory system can be used to 
drive softwiu'e siititilations of various cache memory ar- 
rangements as well as metre comprehensive CPU and 
ntemoiy or system simulations. 

TV^o data capture flevlres ate corninordy aseti in cor\j unc- 
tion witii the TMON. The llrsl. nti 111* n>o()0 logic analyzer 
configured with optional system perftmnance analysis 
software, generates two main types of data One is a his- 
togram that shows the occurrence mix of a user-defined 
subset of the possibh: iW (ycle tyijes (Fig. 3a). The per- 
formance analysis software aveny^es lOOd satnples f if 
cycles from the PMON on the Oy, giving a randomly 
sampled profile of processor activity throughout the dura- 
tion of a performance benchmark. The second type of 



data provided by the HP lB50t) is real-time calculation of 
the mininumi, maximum, and avenige time intervals lie- 
tween the beginning and end of iLser-defined events (Rg, 
3b). The performance analysis software averages rhe in- 
terval ciilculations on the fly ov^er a lai^e number of sam- 
ples to give, for example, iiie average mterarrival time of 
writes to video memory in a CAD apphcation. 

The other data capture device used with the PMON is a 
less intelligent but higher-capacity logic analyzer. This 
instnmient has a 16-megasam pit* deep Trace buffer (as 
opposed lo the 1000-sample dt'ep Ijuffer m lite HP HiflOO). 
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C'ycles IVoin the PMON are captured in tiiis buffer in real 
Lime and the data is later archived to a host computer's 
hard disk. TIte buffer typically holds four to five seconds 
of continuous bus cycle activity generated by a 25-Mhz 
Intel486 microprocessor running an MS-DOS -' application. 
The data c^in tlien be used to drive software simulations 
or processed to create summary reports^ such as an ad- 
dress ran^e siUTiniary of how the processor's address 
space is used by operatmg systems and application soft- 
ware (see Fig. 4). 

Backplane I/O Activity Monitor 

The backplane I/O activity monitor, or BIOMON, also cap- 
tuies information from a personal computer's hardwaiCf 
but instead of the CPU actl\aty', the I/O activity on the 
ISA (Industry Standard Architecture) or EISA (Extended 
Industi'y Standard Architecture J backplane is monitored 
(Fig. 5). The BIOMON consists of two back])lane I/O 
cards: tlie qualify and captiu^c card and the monitor card. 
The qualify and capture^ card resides nonir^vasively in the 
SLT (system mider test) and is connected \1a a ribbon 
cable to tfie monitor card, which is located in anotlier 
personal computer caOed the monitor system. The moni- 
tor system receives, stores, and processes the I/O events 
captured on the SUT's backplane. 

During operation the qualify and capture card is loaded 
witl^ capture enabh* Oags for each of the I/O addresses 
whose activity is to be monitored on the SIT backplane. 

Once the qualify ai\d captine card is set up, I/O address 
accesses on the SUTs backplane cause an event infoima- 
t ion packet (address, data, etc.) lo be transferred to a 
nnijt'in, (Irst-out (FIFO) holding buiTer, allowing for 
asynchronous operation of the SfiT <urd tlie monitor sys- 
tem. The FIFO is unloaded by transferrir^g each event 
information packet to the monitor system's extended 

'MSrDOS IS a U.S; rBgisTered trademark af Mfcrasoii Corp. 
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memory. At the end of event capture, this trace of I/O 
events can be either stored to hard disk or Immediately 
postprocessed for analysis. 

One vei7 powerful use of BIOMON is die perfonnance 
analysis of marked code, which is code that has been 
modified to perform I/O writes at the beginning and end 
of specific events within a software routine. Tlie frequen- 
cy of occurrence and execution time for each marked 
software event can then be analyzed under different con- 
figurations to find existuig or potential bottlenecks and 
the optimum operating environment. 

As an example, the performance mialysis laboratory has 
fleveloped a special installable software filter that wTites 
to specific 1/U adciresses at the beginnuig and end of DOS 
and BIOS (Basic I/O Systeml inteixupts. For our pur- 
poses, a write to I/O i)Oi1 200 (hexadecimal) denotes the 
beginning of an interrupt, and a write io purl 202 denotes 
the end of an interruj^t. The trigger address compai-ator is 
told to capture data for I/O addresses 200 anfi 202, and 
any normal application using DOS or BIOS functions is 
iim on Uie SLfT. The resulting trace can be postprocessed 
to show which DOS and BIOS routines were used by the 
application, how many times each one was called, and 
how long I hey exec uted (Fig. 6a). Other infonnation such 
as tlie interarrival time between events, exclusive versus 
inclusive service time for nested events, and total time 
spent in various apphcation areas can also l^e extracted 
(Fig, tib). Aialysis of this infonnation can assist the soft- 
ware engineer in optuiuzing frequently-used functions in 
DOS and the BIOS. 

This technique can also be used lo analyze protected- 
mode operating systems such as OS/2 and DNIX.^"'^ How- 
ever, becaiLse of thcLr nature, these environments must 



"'UNIX IS a registered tinriemark of UMIX Svsiem LaboTatones in the USA and other coun 
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have tags emb*Hided into the operating system code, (Pro- 
tected-niode operating systems do not allow a user to 
arbitranly write to specific I/O locations/) 

Another use of the BIOMON is lo trigger on reads and/or 
writes to I/O locations associaN^ \\i\h accessory c^ards 
such as disk controllers, serial and parallel interfaces, 
%ideo cards, and so on. For instance, the interarri\^ rates 
of data read from a disk controller could be examined to 
deiennine the actual data transfer rate attained by the 
disk mechanism or drive controller subsysrenL Additional- 
ly, hy momioring the disk t:ont rollers command registers, 
an application's disk I/O can be fully characterized. 

Software-Based Tools 

The software-based tools used by the performance labora- 
tory allow smiitJation t>f ctifferent memory architectures. 

Cache Simulator 

The cache simulator Ls a trace-driven siniulalion based on 
rlie Dinero cache simulator from the University of Califor- 
nia at Berkeley ' Tl^e simulator takes 4is its inpul a list of 
memoi>' accesses (trace file] and parameters describing 
the cache to be simulatcrl. These parameters include 
cache size, line size, assoc"iativiiy, write policy, and re- 
placement algorithm. Tlie cache simulator reads tlie 
memory accesses from the trace file and keeps statistics 
on the cache hit rate and die total bus traffic* lo imd from 
maiti memory. When tlie entire trace file has been read, 
the simulator generates a report of the cache statistics. 

A trace file is generated by connecdng the PMON to a 
CPU and storing all the memor>' accesses on the CPU 
bus to the high-capacity logic jm^Jyzer descTihed above. 
Hie data collected from die analyzer can lattT be (!own- 
loadcd to a host personal computer and archived to hard 
disk. To get useful data from I he simulator, however, the 
input trace file must be If>ng erujugii Id "prinu^*' the simu- 
lated cache. The fn-si several thousand mernor>' atx^esses 
in the trace file will be misses I lint filJ up tlie initially 
empty cache. The shtiulator will report artificially low hit 
rates, because in a real systetti the cache is nc^ver con;- 



pietely empty^ If the ixace file is significantty longer than 
Np*, priming effects are minimized, UTien simulating a 
128K*byte, 2-way associative cache external to the In- 
tel486. Nj, is approximately 40,000.- The high-capacit>^ 
logic anal>^er mentioned above is able lo store 16 million 
memorj^ accesses from the Inlel486 via the PMON. A 
trace file containing 16 million accesses restUts in a prim- 
ing error of less than 1% in the hit rate calculation (as- 
suming a hit rate of approximately 90% for the 128K-i>yte, 
:2-way cache). 

Memory Subsystem Simulator 

Tlie inemorv^ subsystem simulator, a program written in 
C++, is a true event-driven sinuilation that keeps track of 
tiuie miher than just statLstics. Ii builds on the cache sim- 
ulator by integrating it into a more comprehensive model 
that simulates acce.ss tune to memory, li accepts a param- 
eter file that includes cache parameters, DRAM and 
SRAM access times, and oiher metiior> arciuteciure pa- 
rameters. Ii also reads in a PMON trace llle, idt hough this 
one niust contain all accesses (not jtist memory'), and 
their durations so that the sirimlator can keeii track of 
time. The restilt is essentially a nuining time fcjr tlie input 
irac:e file, along with statLsdcs on all aspects of the 
memory subsystem. 

This simulator can be used for making design traile-offs 
within a memory subsystem, such as cache size ajKl orga- 
nization, DRM1 speed, Interleave, page size, and write 
bnffer depth. Fig. 7 sliows the sample results of a 
memory subsystem simulation of relative memoiy^ per- 
formance v^crsus external cache size for a 33-MHz In- 
lei486 running a t>picid DOS application. By simulating 
various design altemalives in advanc(\ \hv design engi- 
neer can arrive at a memory architecture that is tuned for 
optimum performance before contmitting to hardware. 

Conclusion 

The performance analysis hiboratoiy of HP's Personal 
Computer tiro up has developed a suite of hardware and 
software tools to aid in the design process. The hardware 
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Fig. 7. Sample msulLs of a niernoiy subsystem siraiitation of relative 
memory perforniance versus external cache size for a 33'MI^z 
l!dei486 nmning a l^T^ical DOS applieatioHH 

tools give desi^ engineers insight into the low-level per- 
foitriaiice of existing systems, arul tlie software tools use 
the data procJuced by ilie hardwate tools t-o predict the 
perfonnance of future architectures. 

The perfonnance tools were used extensively in designing 
the HP Vectra 486. and more recently the Vectra 486/33T 
The tools helped show thai a burst memory controller 
(described on page 78) was a better price/perfomiajtce 



solution than an external mcmoTy cache for the 25-MH2 
Vectra 486^ and that an exteniaJ cache was a necessity 
for the 33-MHz VecUa 48f3/3;3T. The tools also helped pre- 
dict the performance gain of memory write buffers in a 
Vectra 486 system. This resulted in tlie addition of write 
ijuffei^ to the Vectra 486/33T memory architecture. 

Aeknowled gm e n ts 

The original PMON was designed by Carol Bassett and 
Mark Browfi. Later versions were implemented by Steve 
Jtirvetson, BlOMON's design owes thanks to several peo- 
ple. Its predecessor was designed by Bob Campbell and 
Greg Woods. Subsequent help came troin Ali Ezzet, Chris 
Anderson, and Jolui Wiese, Greg Woods coded the instal- 
lable filter and the original postprocessing program. Jim 
Christy provided additional software help. 
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